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About This Book 

The Vera 4.0 User's Manual is designed to introduce you to Vera-HVL and explain how to de- 
velop Vera testbenches for use with Verilog and VHDL designs. The book discusses the basic 
components of the Vera language and progresses to advanced testbench design topics. The 
book is designed to serve as a supplemental teaching guide as well as a reference guide for the 
advanced user 



Audience 

This book is intended to be used by engineers with experience with either Verilog or VHDL. 
Because Vera is used to create testbenches that link with Verilog and VHDL hardware designs, 
you should have a fundamental understanding of the description language you are using. This 
book also assumes a limited verification background. Finally, this book assumes use of a high- 
level programming language such as C, C++, or Java. 



How to Use This Book 

The first chapter of this book is designed to give an overall view of Vera-HVL and explain 
why it is different than other industry standards. Chapters 2-7 describe some of the basic Vera 
components. Advanced topics are covered in chapters 8-19. 

These are the chapters and a brief description of each: 

• Chapter 1. - Introduction to Vera 

This chapter introduces Vera and briefly describes some of the major features that make it 
one of the premier verification tools in industry. This chapter discusses the flow of data 
using Vera and briefly explains how this flow relates to testbench design and usage. 
Finally, this chapter includes brief examples that illustrate basic Vera usage models. 
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• Chapter 2. - Installation and Setup 

This chapter details how to install Vera and setup a user environment. The chapter 
includes licensing information. It also includes instructions on how to recompile HDL 
simulators to link to the Vera simulator. Support information is also located in this chapter. 

• Chapter 3. - Vera-HVL: The Language 

This chapter introduces the basic lexical conventions of Vera-HVL. It discusses the various 
data types and variable types. This chapter also details some of the more complex data 
types, including arrays and enumerated types. 

• Chapter 4. - Basic Vera Programming 

This chapter discusses the basic components of a Vera program. It includes discussions of 
signal declarations and signal operations, including driving and sampling signals. This 
chapter also includes a detailed discussion of creating subroutines within Vera. 

• Chapter 5. - Sequential Control 

This chapter covers the sequential flow constructs of Vera, including if statements, case 
statements, and for and while loops. It also includes information on sequential flow 
control. 

• Chapter 6. - Concurrent Control 

This chapter discusses the concurrent flow control capabilities of Vera. It includes a 
detailed discussion of concurrent processes. It also covers triggers, semaphores, regions, 
and mailboxes, which are key components to controlling concurrent processes. 

• Chapter 7. - Predefined Vera Tasks 

This chapter documents the majority of Vera's predefined tasks and functions. Included in 
this chapter are the tasks and functions associated with file input and output,, 
randomization, and error handling. 

• Chapter 8. - Object-Oriented Programing 

This chapter is a brief tutorial on object oriented programming. It describes the basic 
components of object oriented programming and details some of the more advanced 
features such as inheritance and polymorphism. 

• Chapter 9. - Automated Stimulus Generation 

This chapter is a detailed discussion of Vera's stimulus generation features. This chapter 
covers the randomization of test packets, constraint-driven stimulus generation, and data 
packing and unpacking. 
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• Chapter 10. - Vera Stream Generator 

This chapter discusses the Vera Stream Generator. It includes an introduction to sequence 
generation and includes complete coverage of the system tasks and functions incorporated 
into the stream generator that allow data passing between productions. 

• Chapter 11. - Functional Coverage 

This chapter begins with a brief overview of functional coverage and explains the inherent 
advantages over code coverage. It discusses the use of monitor bins to track simulation 
activities. This chapter also details how to set up complex coverage objects that can be 
used for cross-correlation between events. 

• Chapter 12. - Multiple Module Support 

This chapter documents Vera's multiple module support. It details how to create 
testbenches using multiple main programs and incorporate them into a single testbench. It 
covers generation of testbenches using this methodology as well as specific enhancements 
designed to ease testbench creation. 

• Chapter 13. - Vera-CORE 

This chapter introduces Vera-CORE, a feature designed to assist IP vendors and their 
clients. This chapter includes usage models for both the IP vendors and the core users. 

• Chapter 14- - Vera-to-HDL Task Calls 

This chapter provides information on how to make Vera task calls from HDLs and vice 
versa. The specific constructs are discussed along with some of the inherent limitations. 

• Chapter 15. - Calling C/C++ Functions 

This chapter discusses how to incorporate user-defined functions written in C or C++ with 
your Vera testbench. It includes information on how to link in dynamic libraries as well as 
how to call those functions from Vera. 

• Chapter 16. - VERA-SV API 

This chapter covers Vera-SV, which allows you to run distributed simulations with some 
Vera modules and some C modules. It includes information on system tasks and functions 
designed to enhance the distributed simulation capabilities of Vera. 

• Chapter 17. - Testbench Setup and Usage Notes 

This chapter discusses how to connect testbenches to the design under test. It includes 
instructions on how to connect HDL signals to the Vera testbench. It also details how to set 
up multiple clocking domains in both Verilog and VHDL. 
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• Chapter 18. - Compilation 

This chapter covers all of the compiler options used when compiling Vera source code. It 
also includes details on how to use the Vera simulator stand-alone. This chapter discusses 
modular compilation as well. 

• Chapter 19. - Vera Source-Level Debugger 

This chapter describes the Vera source-level debugger. It describes how both the 
text-based and graphical versions of the debugger are used. It explains each of the major 
debugging features incorporated into the debugger. 
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Conventions 

This book uses several style and syntax conventions: 

• Vera keywords are printed in bold. 

• Variables are printed in italics. 

• Signal names, bind names, and user-defined functions are printed as: signal name, bind 
name, user function. • 

• Vera statements and variable definitions are printed as: 

cammand_keyword {variable, argrument) ; 
variable - The definition of variable is described here. 
argument - The definition of argument is described here. 

• Optional arguments are encapsulated by bold brackets ([ 1): 

command_k*yword (variable [. argument] ) ; 
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1. Introduction to Vera 

This chapter discusses the current industry standards for high-level design verification, and it 
briefly details the history of Vera. It includes these sections: 

• High Level Verification 

• Why Vera? 

• What Can Vera Do? 

• Overview 

• A Small Example 

• Multiple-Clock / Multiple-Module Systems 

• Simple Example of a 2-Clock System 



1 .1 High Level Verification 

Technology is advancing today perhaps faster than even New innovations in both hardware 
and software are extending the capabilities of our computers and building a foundation for an 
even more accelerated world of changes and technological advancements. The speed at which 
these changes are taking place demands that industry engineers be able to design, build, and 
debug new products with increasing accuracy while still producing them fast enpugh to meet 
industry standards. 

The stress on design integrity is no more evident than in the design and manufacture of inte- 
grated circuits. And while engineers have managed to keep designs ahead of the technology 
curve thus far, the complexity of current designs and the time to verify their functions is be- 
coming a serious concern for chip designers. 

To help in the design process, a number of programming knguages have been developed to 
simulate and test hardware design. To that end, Verilog and VHDL have grown increasingly 
popular in testing design specifications. The power they bring to'the engineer to ensure design 
integrity has paved the way for still more sophisticated designs. 

However, in this design world, the reality is that upwards around 75% of the time spent to get 
a chip from inception to market is spent verifying chip design. Even with the power that Ver- 
ilog and VHDL bring, designs are becoming increasingly difficult and time consuming to val- 
idate sufficiently. To continue to create increasingly complex systems on a chip at the pace 
demanded by the public, engineers need more powerful tools. Hence, Vera was bom. 
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1.2 Why Vera? 

The key to understanding the difference between the current HDLs and Vera-HVL lies in the 
inception of each. The HDLs are designed to be Hardware Description Languages. As such, 
they are adequate for developing hardware models. Vera-HVL is designed to act as a Hard- 
ware Verification Language. Its role exists in an entirely different scope: the verification of com- 
plex ICs and systems. 

The current HDLs are adept at creating hardware models, which are made up primarily of 
static concurrent processes that simulate individual parts. However, the HDLs provide a level 
of abstraction that is far too narrow to develop useful test environments. The lack of concur- 
rent flow control devices greatly limits the use of multiple threads to simulate a real test envi- 
ronment Engineers have resorted to programming language interfaces that provide links to C, 
C++, and Perl, but even these fall short because these other languages have no concept of 
hardware, timing, or concurrency. 

Vera-HVL provides the necessary abstraction level to develop reliable test environments. 
Through the use of complex synchronization and timing mechanisms, concurrent processes 
can be run that simulate a dynamic test environment. The implementation of the object orient- 
ed programming methodology further enhances the ability of the language to work with com- 
plicated designs and sophisticated test benches. 

Add to this Vera's self-checking capabilities, automated stimulus generation, dynamic cover- 
age analysis, and modular approach to programming, and the power of Vera is quite apparent. 

1.3 What Can Vera Do? 

Vera is designed to be a hardware verification language. To accurately simulate complex test 
benches that interact with complicated designs, Vera has a host of features available to its us- 
ers. 

Automated Stimulus Generation 

As chips have grown increasingly complex, the ability to write and perform tests on all the 
functions of a system has become nearly impossible. Testing for specific behavior, while possi- 
ble, is far too time-consuming to be a viable verification method. Instead, engineers need a 
method of testing the device under varying conditions arid stimuli. To meet these needs, Vera 
provides the engineer with automated stimulus generation. 

The automated stimulus generation process allows engineers to use random stimuli to drive 
the device under test By randomizing the stimuli, engineers can simulate tHe device under 
more conditions and in less time than with manually-written code. 
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Vera further enhances the automated stimulus generation feature with constraints that give 
the engineer control over the random testing of the chip. The constraint mechanism grants the 
engineer two key advantages: (1) the engineer can weight the tests so that certain sets of stim- 
uli occur more often to simulate a more real environment, and (2) the engineer can use the 
constraints such that the current model state affects future tests. 

Coverage Analysis 

Because of the complexity of chips and broad scope of functions that need to be tested for any 
given chip or system, the completeness of verification is a key issue. While code coverage 
yields information about specific lines of code, it does not give any detailed information con- 
cerning functionality. Thus, code coverage is no longer sufficient for complex model verifica- 
tion. 

Vera supports a powerful coverage analysis suite that assures the engineer of the desired cov- 
erage. Specific activities are monitored to ensure that all legal states and transitions have been 
tested. These activities can also be time-stamped to check that specific events happen simulta- 
neously. 

Vera provides two methods of coverage analysis: open-loop and closed-loop analysis. Open- 
loop analysis performs the tests and then creates a report summarizing the results. Closed- 
loop analysis offers significantly greater power. Using closed-loop analysis, the test suite iden- 
tifies areas of sparse coverage and uses that information to drive subsequent tests. This ap- 
proach guarantees completeness of verification while reducing effort and time spent 

Virtual Ports 

Vera provides a simple way to re-group or re-name interface signals by creating virtual ports. 
Virtual ports allow the engineer to group interface signals so that they can be used more easi- 
ly. These are particularly useful when calling subroutines that you want to act on various in- 
terface signals. By grouping the signals, you can pass them to the subroutine as an argument, 
allowing you to create signal-independent subroutines. The logical grouping reduces the 
amount of code required to run tests, and makes it easier to comprehend. 

Distributed Simulation . 

Distributed simulation is often used with, but not limited to, hardware/software co-verifica- 
tion. It involves verifying large designs by partitioning verification tasks to run concurrently 
across multiple processors. Vera supports distributed simulation by enabling multiple Vera 
programs and C/C++ applications to execute remote calls to each other across a computer net- 
work. This is particularly useful when verifying complicated systems that tax computer re- 
sources. Distributing the simulation across multiple servers makes the simulation faster and 
more efficient 
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Object Oriented Programming 

Object-oriented programming is at the very core of Vera. The implementation is clear, straight- 
forward and elegant assimilating and extending the best of the features found in C++ and Ja- 
va. By using the object-oriented methodology, programs are easier to design, easier to develop, 
easier to debug, easier to maintain, easier to share, and easier to re-use. 

Object-oriented programming leads naturally to grouping related code and data together, 
keeping these sections small, easy to understand, easy to debug and easy to maintain- The re- 
sult is a discipline and program structure that is useful for small programs, but has a dramatic, 
powerful impact on your productivity as soon as your program becomes large or in any way 
complex. 

Verification-Specific Advantages 

Several other key features have been implemented in Vera to enhance its verification capabili- 
ties: 

• Vera supports project-based configuration. Project-based configuration allows the engineer to 
create test benches that are independent of the actual connections to the simulation environ- 
ment, and connect those testbenches to any point in the simulation hierarchy without the need 
for a test-top configuration. So, the engineer can run separate test benches with separate pro- 
gram modules concurrently. 

• Vera provides a set of complex synchronization mechanisms that allow you to use concurrent 
processes in a much more dynamic way. The use of events, regions, semaphores, and mailboxes 
lets you synchronize multiple signals and threads and simulate complex systems with greater 
ease. 

• Because Vera is designed to verify existing hardware description models, it can interact with 
both Verilog and VHDL designs. This means that engineers can create testbenches in Vera that 
will interact with existing Verilog and VHDL code. 

• The modular approach used by Vera makes the use of multiple test benches easy and efficient 
Changes to the hardware design do not require recompilation of Vera testbenches. Further, 
changes to a testbench require that only the changed testbench be recompiled. 

1 .4 Overview 

This section explains the basics of Vera and how it is used in a real-world context 
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1.4.1 How Vera Is Used 

Vera is typically used to develop regressible, self -checking tests for hardware designs. Vera 
test benches are created and linked to existing HDL hardware models using Vera's interface 
construct Then the Vera driver provides all or most of the stimuli to the device under test 
(DUT). These stimuli simulate input that would be generated by other units in the real system. 
Thus, Vera's role is fundamentally to simulate the external systems that would drive the de- 
vice in a real environment 

Figure 1-1 diagrams Vera's basic usage model. 



• Behavioral 
models 

• Hardware 
models 

• Other 



Figure 1-1 Typical Vera-CS usage model 

Behavioral models can also be added where appropriate. Memory models and other highly-al- 
gorithmic modules are good candidates for behavioral implementations rather than mimick- 
ing the features with Vera code. Such models can be written in the HDL or Vera (depending on 
the required functionality). 

1.4.2 Vera Components 

The Vera verification suite includes Vera-HVL, the verification language and language compil- 
er; the Vera virtual machine, which connects to Verilog and VHDL, and Vera-CS,: the qyde- 
based simulator. The simulator can be used as a stand-alone simulator; but is most often used 
in conjunction with Verilog and VHDL designs. 

The Vera virtual machine runs with the Verilog and VHDL simulators, using user-defined in- 
terfaces to convey signal values between the Vera and HDL domains. Each interface is defined 
by two main elements: the signals used to drive and sample HDL nodes and a dock that spec- 
ifies all signal timing. The dock determines when signals are driven. and sampled. 



Test bench 
Vera-HVL 



Vera Simulator 
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Simulations are governed by clock edges. All events occur at rising and falling clock edges 
(+/- any skew). As the HDL simulators detect these clock edges, they pass control to Vera. 
Then Vera runs its code non-preemptively until it reaches an HDL interface primitive such as 
drive or expect To execute the primitives, Vera passes control back to the HDL. Because the 
Vera code is run non-preemptively, no simulation time passes while the Vera code executes. 

Vera Simulation 



HDL Simulation 



Figure 1-2 HDL and Vera Execution 

In addition to being able to run with the HDLs, Vera-CS can run with functional circuit models 
written in C or other languages. 

1.4.3 Vera/HDL Flow of Data 

It is helpful to identify three major regions in the Vera/HDL environment: the Vera domain, 
the HDL domain, and the Vera/HDL interface. Each region has several key components. 

The Vera Domain 

In the Vera domain, there is Vera-HVL, the Vera virtual machine, and a Vera compiler. The 
Vera compiler compiles code written in Vera-HVL and translates it into an intermediate form 
used by the simulator. This intermediate form (.vro object files) can be generated from both 
the main Vera program and any subprograms that may be included. Note that they can be 
compiled separately and linked at simulation time. 

The HDL Domain 

In the HDL domain, there is the hardware description model coded in the HDL and the HDL 
simulator. The HDL simulator acts in conjunction with the Vera simulator across the Ve- 
ra/HDL interface. 

The Vera/HDL Interface 

The Vera/HDL interface is the most important region of the Vera/HDL environment It in- 
cludes an interface construct, an HDL shell, global variables, and HDL tasks that will be called 
within Vera. 

The interface construct maps signals from the HDL domain to the Vera domain. It specifies 
which signals will be observed and controlled, and determines the flow of data back and forth 
between the two domains. 

The HDL shell is generated by the Vera compiler. It instantiates the interfaces via PU calls. 
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The global variables and HDL tasks are the shared variables and tasks that are used in both 
domains. 

Figure 1-3 shows a schematic of the flow of data within the Vera/HDL environment. 



Verilog shell Verilog-HDL Circuit 




Vera object code 

' Vefa for a sub-program 

sub-program 

Figure 1-3 Vera Environment Row 



A Small Example 

To understand how Vera can be used, we follow the process of verifying a simple Verilog 
module in this chapter. See the tutorial for additional examples ($VERA__HOME/ tutorial). 
The following Verilog module is a 2-input round-robin arbitrator. 

module rraxb (request, grant, reset, elk) ; 
input 11:0) request; ( 
output [1:0] grant; 
input reset; 
input elk; 
wire winner; 
reg last_winner; 
reg [1:0] grant; 
wire [1:0] next_grant; 

assign next_grant [ 0 ] 

- -reset & (request [0] & 

(-request [1] | last_winner) ) ; 
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assign next_grant [ 1 3 

= -reset & (request [1] & 

(-request [0] | -last_winner) ) ; 

assign winner 

= -reset & ~next_grant [ 0 3 & 

( las t_winner | next, grant [ 1 ] ) ; 

always ©(posedge elk) begin 

last_winner = winner ; 

grant = next_grant ; 
end 

endmodule 



The Veriiog and Vera source code for this example are available in $VERA_HOME/ sam- 
ples /arbiter. Running the Vera template generator (vera -tern) creates a simulation en- 
vironment and a test template. The following command line will generate three files, 
rrarb. test_top.v, rrarb. if. vrh and rrarb . vr . tmp: 



vera -tem -t rrarb -c elk rrarb. v 



In the command line, -t specifies the name of the module to be tested, -c specifies the dock 
input (optional), and the last argument, rrarb. v, specifies the Veriiog file name. 

The first file rrarb . tes t_top . v generated by vera -tem is the Veriiog simulation top file: 

module r rarb_t es t_top ; 

parameter Simula tion__cycle = 100; 

reg SystemClock; 
wire [1:03 request; 
wire [1:01 grant; 
wire reset; 
wire elk; 

assign elk = SystemClock; 

vera_shell vshelM 

. SystemClock (SystemClock) , 
. rrarb_reques t ( reques t ) , 
. rrar b g rant (grant) , 
.rrarb_reset (reset) , 
.rrarb_clk(clk) 

) ; 



rrarb dut ( 

-request (request) , 
.grant (grant) , 
.reset (reset) , 
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.clk(clk) 

) ; 

inital begin 

SystemClock =0; 
forever begin 

# (simulation_cycle/2) 

SystemClock = -SystemClock; 

end 
end 
endmodule 

In the top file, the module rrarb is instantiated as dut (device under test) and connected to 
the vera_shell module. The Vera virtual machine uses this vera_shell module to inter- 
face to the Verilog world. A clock signal SystemClock is generated and connected to 
vera.shell's SystemClock. This signal is used to count simulation cycles in the Vera world. 
The input elk is also driven by SystemClock since -c option was specified. Note that in sys- 
tems with multiple clocks and multiple interfaces, elk and SystemClock can be indepen- 
dent. 

The second file, rrarb. if . vrh, contains the interface and signal definition. This file is includ- 
ed in the third file, the template file, right before the program declaration. 

interface rrarb { 

output [1:0] request OUTPUT_EDGE OUTPUT_SKEW; 

input [1:0] grant INPUT_EDGE; 

output reset OUTPUT_EDGE OUTPUT_SKEW; 

input elk CLOCK; 

) 

In this interface file, an interface rrarb is defined with signals on the rrarb module body. 
Output signals of the rrarb Verilog module are defined as inputs, and inputs of the Verilog 
module are defined as outputs in the Vera program interface, except for elk, which is driven 
by verilog top (since the -c option was specified). 

The third file, rrarb . vr . trap, is the Vera program template file: 

# include <vera_def ines . vrh> 
fdefine OUTPUT_EDGE PHOLD 
♦def ine OUTPUT_SKEW #1 
fdefine INPUT_EDGE P SAMPLE 
♦include "rrarb. if .vrh* 

// tasks/functions 

program rrarb_test 

{ // start of top block 
// global variables : 



Synopsyslnc. 



// start of test program 



26 Chapter 1. Introduction to Vera 



Vera 4.0 User's Manual 



// Example of drive: 

// rrarb. request = 0; 

// Example of expect: 

// rrarb. grant == 0; 



} // end of program rrarb_test 



rrarb_test_top 



vera_shell 
vshell 

SystemQock 



request 


rrarb 


grant 


duv 


reset 


dk 



& 



I 



Figure 1-4 Top level connection 

Using the template, we can easily write the test code. First, both requests are driven to 0 and 
rrarb. reset is asserted to initialize the internal states. Then grants are checked for each re- 
quest. Finally, both requests are asserted simultaneously, and the round-robin control is 
checked. 



♦define OUTPUT_EDGE PHOLD 
♦define OUTPUT_SKEW #1 
♦define HTPUT_EDGE PSAMPLE 
# include <vera_de fines . vrh> 
♦ include 'rrarb. if .vrh* 

program rrarb_test 

{ // start of top block 

// reset 

rrarb. request = 2'b00; 
rrarb. reset = 1; 
61 rrarb. reset = 0; 



// simple requesting 
61 rrarb. request = 2'b01; 
61 rrarb. grant == 2'b01; 
rrarb. request = 2'b00; 
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@1 rrarb. request = 2'blO; 
ei rrarb. grant == 2'blO; 
rrarb. request = 2'bOO; 

// round- robin test 
81 rrarb- request = 2'bll; 
61 rrarb. grant == 2'b01; 
61 rrarb. grant == 2'blO; 
rrarb. request = 2'bOO; 



// requesting both port 
// should get grant 0, since last was 1 
// keep asserting both port, get gnt 1 

// negate 



} // end of program rrarb_test 

This command line compiles the file: 
vera -cmp rrarb. vr 

The Vera compiler will compile the rrarb. vr and generate two files: rrarb. vshell, a Ver- 
ilog file that contains the vera_shell module, and rrarb. vro, the Vera object file. 

Now run the simulation using Vera with Verilog-XL by typing: 

verilog rrarb. test_t op. v rrarb. v rrarb. vshell +vera_load= rrarb. vro 



You see a Verilog simulation message such as: 

VERILOG-XL X.X MMM DD, YYYY HH:MM:SS 

* Copyright Cadence Design Systems, Inc. YYYY, YYYY. 
Compiling source file -rrarb. test_top.v" 
Compiling source file • rrarb. v* 
Compiling source file f rrarb. vshell* 
Highest level modules: 
rrarb_test_top s 

Vera: finish encountered at time 
: total mismatch: 0 

* vca_ error: 0 
fail < expected) : 0 
drive: 9 
expect: 4 
sample: 0 
sync: 0 

Type ? for help 
Cl> 



850 cycle 9 



1.6 Multiple-Clock/ Multiple-Module Systems 

Vera supports complex docking with any number of derived or independent clocks as well as 
asynchronous interactions that fall outside the scope of clocking. Understanding the concepts 
in this section is critical in handling system testing and multiple clocks. 

_ 
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Vera's SystemClock gives Vera a notion of time (cycle number). There are several operations 
that use this as a convenient reference signal In most cases, it makes sense to tie the System- 
Clock to the actual system clock, but in others it might be offset or derived from another ref- 
erence. 

Most operations are tied to the timing of the actual signals. Independently of SystemClock, 
you can define any number of clocking domains (a "Vera interface"), each with its own clock 
reference. 

In simple systems with just one interface, the real system clock, SystemClock, and the inter- 
face clock might be tied together, or just derived from one common signal by assigning differ- 
ent delays. Vera itself imposes no restrictions on the relation between the real system clock 
(Vera's reference) and the clocking for each interface. 

Hence, interfaces in Vera are related to the timing of signals as opposed to the boundaries of 
modules or any such implementation-related issue. When you define an interface, you assign 
to it a clock reference. 

Note that you cannot have multiple clocks on a single interface because the clock defines a 
clocking domain (interface). Instead, split your signals across multiple interfaces, each one 
with its own clock. 

Sometimes the question arises "can I haye multiple clocks in an interface?" The answer is: "no, 
it doesn't make sense - the clock defines a clocking domain (interface) - what you probably 
want is to split your signals across multiple interfaces, each one with it's own clock." 

As a final note, driving of synchronous signals is statically tied to a given clocking domain for 
the duration of a testbench. However, sampling can be done in multiple clocking domains by 
connecting a Verilog signal to multiple Vera interfaces. 



1 .7 Simple Example of a 2-Clock System 

In this example we will have a system in which there is a clocking module that generates two 
main clocks (clkl and clk2). The system contains two major portions, each one running from 
its own clock. 



P SAMPLE #-1 PH0LD #6 

P SAMPLE <-2 PHOLD #5 

NSAMPLE #0// cample on falling edge 

PHOLD #3 



// ... 

fdefine TIMING_A 
fdefine TIMING.B 
fdefine TIMING_C 
#def ine TIMING.D 



// connect signals to clocking domain 1 
interface subsysl { 

inout [31:0] data TIMIKG_A verilogljiiode • sys. a. subsysl. D[31 : 0] • ; 
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output [63:0] addr TIMING_D verilog_node -sys.b.subsysl.A[63 : 0] • ; 
input elk CLOCK verilog_node •sys.clk_gen.clkl'; 
input str TIMING_C verilog_node -sys.str"; 

// 

} 

// connect signals to clocking domain 2 

interface subsys2 { 

inout U6:0] data TIMING_B verilog_node • sys. subsys2.D [16:0] ■; 
output [32:0] addr TIMING.D verilog_node -sys.subsys2 .A[32 :0] ■ ; 
input elk CLOCK verilog_node ■sys.clk_gen.clk2*; 
input str TIMING_C verilog_node "sys. str - ; 

// 

) 

// connect Vera's SystemClk to -sys.sysclk- 
verilog_node CLOCK 'sys .sysclk' ; 
//-.. 



In this example, Vera will drive subsysl .data 6 time units after the rising edge 
subsys 1 . elk (same as sys . clk_gen . clkl) and sample it 1 time unit before the rising 
edge. 

The SystemClock (the same as sys . sysclk) is used only in relation to calls such as 
get_cyele ( ) , or operations as § (CLOCK) . All other sampling, driving, synchronization, etc, 
operations involve specific signals, so they use the timing specified in the corresponding inter 
face clocks (rather than SystemClock). 
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Note that the Verilog node sys . str is being observed in both timing domains (as 
subsysl . str and subsys2 . str, respectively). The only difference is that in each domain we 
are using a different clock reference and a different offset within the clock. You can use multi- 
ple clock references to sample a signal, but you must choose one clock reference to drive. 
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Figure 1-5 Multiple Modules and Multiple Clocks 

There are no restrictions in terms of how each one of these clocks are related. In fact, they can 
even stop and continue independently. Vera only tracks their edges. At that point (plus or mi- 
nus any skew), the signals related to the clock that changed may be driven, sampled, etc. (de- 
pending on what the test code may be doing). 
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2. Installation and Setup 



This chapter details the installation and setup of the Vera verification suite. It includes these sections: 

• Installation 

• Licensing 

• Running Vera with Verilog-XL 

• Running Vera with Chronologic VCS 

• Running Vera with the Verilog ModelTech Simulator 

• Running the Vera Stand- Alone Simulator 

• Testing the Installation 

• Vera Support 

2.1 Installation 

1. Create a release directory on the machine you want to act as your Vera server. 

2 . Download the Vera release to the release directory you created. The ftp address is provided by Synop- 
sys. Email vera-support@ synopsys.com for help. 

3. Set the environment variable VERA— HOME pointing to the Vera release directory: 

setenv VERA_HOME <directory_path> 

4. Add $VERA_HOME/bin to your search path. 

2.2 Licensing 

Vera 3.1 and higher uses the industry-standard FlexLM licensing system. 

2.2.1 Licensing for Current FlexLM Users 

If you use FlexLM, check that your Vera key is for the same servers) that show in your current 
$LM_IiICENSE_FILE, add the Vera feature to your license file, and then add the daemon line for 
$ VERA_HOME / bi n / s s i lmd. 

2.2.2 Licensing for Other Users 

Vera uses the industry-standard FlexLM licensing system, which provides floating licenses for a net- 
worked environment. To license your version of Vera, you need to do 4 things: 
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1 . Obtain your Server-ID. 

2. Edit your Flex license file to add the absolute path to the Vera verification tool ($VERA_HOME) and 
the Synopsys license daemon ($VERA_HOME/bin/ssilmd). 

3. Set LM_LICENSE_FILE to point to the license file. 

4. Start the FlexLM license server. 

For more information, use any Web browser to view the HTML data in: 
$VERA_HOME/doc / f lexlm/man . html 

Getting the Server-ID (Imhostid) 

Flex network floating licenses are managed from one server (or more, when redundant servers are set 
up). When you purchase Vera licenses you need to specify the server(s) for which the keys should be 
hosted, including both their name and their Flex-ID. To get the Flex-ID, type the following from a Unix 
shell: 

For SPARC servers: host id 
For all other servers: Imhostid 

The Imhostid executable can be found within the Vera release, in: 

$ VERA_HOME /bin / Imhos t id 
or on the Synopsys FTP site: 

ftp . systems . com 
To use the FTP site: 

1 . Use your FTP tool to connect to the Synopsys FTP site. Log in with the username anonymous and pass- 
word anonymous. 

2. Change to the directory designated for your server type: 

cd /pui/ssi/<server_type> 
where <serverjtype> is sunos, solans, hpux, aix, SGI, or ALPHA. 

3. Make sure you are in binary mode. Download the zipped executable: 

get Imhostid. gz 

4. Download the gzip tool if your site does not already have it: 

get gzip 

5. After exiting FTP, make sure the ripped executable is in the directory you want 
($VERA_HOME/bin/ Imhostid is preferable). Then decompress the zipped file: 

gzip -d Imhostid. gz 
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6. Set the permissions on the executable: 
chmod a+x lmhostid 

FLEXIm License File Contents 

The FLEXIm license file contains 3 important pieces of information: 

1. Server line: 

SERVER <server_name> <servBr_lmhostid> <port> 

Make sure the key you got is for the proper hostidVhostname. There should be only one server line per 
Flex license file. 

For example: 

SERVER mars 12345678 1700 

2. Daemon line(s): 

DAEMON ssilmd < abs olut e_pa th^_ to__ssi lmci_binary> 

You must use the absolute network path WITHOUT environment variables to a copy of the Synopsys 
license daemon found in $VERA_HOME/bin/ ssilmd. In a given FlexLM file there can be 1 daemon 
line for each vendor. 

For example: 

DAEMON ssilmd /net/ jupiter/home/cad/ssi/vera/bin/ssilmd 

3. Feature line(s): 

FEATURE <tool> <daemon> <version> <expires> <num> <Jcey> 
There will be one feature in your LM license file for each tool. 
For example: 

FEATURE vera ssilmd 3.000 31-dec-96 2 BB6E7071B0C8C9877168 

LM_UCENSE_FILE Environment Variable 

You tell FlexLM where your keys are by setting an environment variable as follows: 
setenv LH_LICENSE_FILE <path^to_your_license_£ile> 

Each license file may contain licenses for many packages and from multiple vendors. It is simplest to 
have all your licenses in one file. However, you can specify multiple files as follows: 

setenv LM_LICENSE_FILE <pat3i^to_filel>:<path_to_file2>z<path^to_fileN> 
Add this command to your .login or .cshrc files to ensure that it is executed upon logging in. 
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Starting the Flex License Manager 

If it is not already running on the host server, start the license manager by typing from the Unix com- 
mand line: 

$VERA_HOME /bin/ lmgrd -c <vera_license_file> >& /tmp/f iexlmgrd. log 

If it is already running and you want Flex to know about your update to the license file, enter 
$ VERA_HOME/bin/ Imreread 



Note - Use "lmgrd" version 5.0 or higher. If you arc using an older version 
supplied by another tools vendor, you may need to upgrade to the "lmgrd" 
supplied with Vera (which would also provide the backwards compatibility 
for tools that use older FlexLM versions). To find out the version of a given 
lmgrd, enter lmgrd -v at the command line. 



Versions Enabled and Backwards Compatibility 

License keys for higher versions of the software enable lower versions as well. Also, Vera licenses ig- 
nore any decimals in the version number except for the 1st one (e.g., a key for version 4.40 will enable, 
vera-3.1, vera-4.0, and vera-4.49, but not vera 4.5). 

Versions 3.0 or lower did not use FlexLM. You can run in your environment a mix of Flex and non-Flex 
based Vera versions. However, beware that the license files, servers, and environment variables are un- 
related and cannot be combined. You can have both the old SSI license manager and Flex running, have 
both the old SSI_LICENSE and LM_LICENSE_FILE environment variables set. As long as your 
search path is set to pick the right Vera/HDL versions, you should have no problems. 

2.2.3 Controlling Vera License Queueing 

The environment variable VERA__WA!T_LICENSE allows you to control the checking out and queueing 
order of full and runtime Vera licenses. The syntax from the Unix command line is: 

setenv VERA_WAIT_LICENSE value 

value - The value can be either 1, which queues up for runtime if both full and runtime licenses arc 
unavailable, or 2, which polls for either license every 10 seconds if both full and runtime licenses 
are unavailable. All other values (or if VERA_WAJT„UCENSE is not set) terminate the simulation 
if neither license is available. 



Note - The environment variable SSI_WAIT_LICENSE must not be set. 



2.3 Running Vera with Chronologic VCS 

You must generate a new Chronologic VCS simv executable with each new hardware description. To 
link it to Vera, you need to invoke vcs with the following arguments: 



a) your verilog model(s) 
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b) option "-P SVERA_HOME^ib/vera_pli.tab H to specify the PLI table (or merge this PLI table with 
other ones you may already be using) 

c) the $VERA_HOME/lib/libSysSciTask.a library 

For example, to generate a new simv executable for a design modelv, enter. 

vcs model. v -P $VERA_HOME/lib/vera_pli. tab $VERA_HOME/lib/libSysSciTask.a 
If you are using SunOS, you need to run ranlib before linking the UbSysSciTasLa library: 

ranlib $VERA_HOME/lib/libSysSciTask.a 
If you are using HPUX, you must invoke the following options in addition to those specified previous 



vcs model. v -Mupdate=l -gen_c -P $ VERA^HOME /lib/ vera _pli. tab \ 
$VERA_HOME/lib/libSysSciTask.a -LDFLAGS «-E -a archive_shared« -ldld 



2.4 Running Vera with Verilog-XL 

To use Vera with Verilog-XL, you must link the libSysSciTask.a library into your Verilog executable. 
You must do this only when first using Verilog-XL with Vera. 



Note - Version 3.1p4 of Vera and later versions dynamically load the vera.dl 
library. If you've previously linked your Verilog-XL with HbSysSciTask.a, 
you DO NOT need to relink it. Just change your VERAJiOME environment 
variable, and Verilog-XL will automatically use the vera.dl library in the new 
Vera release. 



Environment ' 

You must have the Cadence binaries and the C-compiler in your search path. To make sure they 
correctly, add the following to your xshrc file: 



setenv CDS_IKST_DIR <path_to_CADENCE_install_directory>/ tools . <arch> 
setenv C_COOTII^^HOME<pat^to_C_conpiler_install_directory> 

# 

# search path 

set path = ($path $CDS_INST_DIR/bin $C_COMPILEIUHOME/bin) 




# tools 
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veriuser.c 

The file veriuser.c contains information that Verilog uses to link in user-defined system tasks. You 
must include these files in your veriuser.c file: 

vmc_veri_f unext . h 
vmc_veri_f undef . c 

If you have other tasks that have to be linked in, such as PowerFault-IDDQ's, you need to combine 
what is included in $VERA_HOME/lib/veriuserx with the veriuser.c for the other tasks. 

vconfig 

The vconfig procedure creates a cr_vlog script, which is used to link Vera into the new Verilog execut- 
able. To run vcongif: 

1. Begin vconfig: 

vconfig 

If you get a message saying: "vconfig: Command not found", it means that your search path is missing 
Cadence's $CDSJNST_DIR/toolsA)in directory. 

2. At the following prompt: 

The user template file 'veriuser.c' must always be included in the link 
statement. What is the path name of this file? 

Enter the path to your own veriusenc. 

3. At the following prompt: 

List the files one at a time, terminating the list with a single ' . ' 

Enter 

. / 1 ibSysSc iTask . a 

Then specify any other libraries you may need to link in (1 per line). After all the libraries have been 
. specified enter a single period (.) on a new line. 

The vconfig program will create a script named cr_ylog (or whichever name you choose when prompt- 
ed). 

Before Running cr.vlog 

If you are using HPUX 9.0 or HPUX 10.2, your crjvlog must use the "-W1.-E" compile option. Change 
the "cc" command from: 

cc -o verilog 

to: 

cc -Wl,-E -o verilog 
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If you are using either Verilog-XL version 2.X OR you are using HPUX 9.0, you musl also link with 
the M -ldld M library. Check that one of the last lines of your cr_vlog file matches the following: 

+03 -lm -1BSD -lcl -N -ldld 
If you are using SunOS, you should run ranlib before running crjvlog: 

ranlib sunos4 . 1/libSysSciTask.a 
If this step is omitted, you will get link complaints when you invoke cr_ylog. 
If you are using Solaris, your cr_ylog script must link with these libraries: 

-lsocket -lnsl -lintl 
Check that these libraries arc included in your cr_ylog script 

Running cr_vlog 

When you run the crjvlog script you will compile a new Verilog executable with the HbSysSciTask.a li- 
brary. To run it, enter 

cr_vlog 

Install the new Verilog executable you created the directory you want to run it from. Note that if you 
chose to name the new executable "verilog", you should have $VERA/bin ahead of $CA- 
DENCE/tools/bin in your search path, so that the right version of Verilog is picked up. 

2.5 Running Vera with the Verilog ModelTech Simulator 

You must recompile your MTI simulator and link it with Vera before running any simulations. To re-" 
compile your ModelTech simulator 

1. Compile veriuserx for the MTI simulator. 

For Solaris, type: _ 

cc -K pic -DMTI -DaccVersionLatest -c -J<modeltecb_xnclude_dir> VT. 
-I$VERJV_HOME/lib veriuser.c 

OR 

gec -fpic -DMTI -DaccVersionLatest -c -Kmodeltech-include_dir> \ 
-I$VERA_HOME/lib veriuser.c 

Then type: 

Id -g -o veriuser.so veriuser.o libSysSciTaskpic .a 
For SunOS, you must ran ranlib HbSysSciTask.a prior to compiling. Then type: 

cc -DMTI -DaccVersionLatest -c -l<modeltech_include_dir> \ 
-I$VERA_HOME/lib veriuser.c - — ^ftr 
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Id -o veriuser.so veriuser.o libSysSciTaskpic .a 
For HPUX, type: 

cc -DMT I -DaccVersionLatest -c +z -I<modeltech_include_dir> \ 
- 1 $ VERA__HOME / 1 ib veriuser.c 

OR 

gcc -fpic -DMTI -DaccVersionLatest -c -I<modeltech_include_dir> \ 
-I$VERA__HOME/lib veriuser.c 

Then type: 

Id -b -o veriuser.sl veriuser.o libSysSciTaskpic .a -lc 
2. Set up ModelTech to load veriuser.so (veriuser.sl for HP). 

Edit vsystem.ini or raodelsim.ini to include: 
tvsim] 

Veriuser = $VERA_HOME/lib/verisure.so 

OR 

setenv PLIOBJS $VERA_H0ME/ lib/ veriuser .so 

OR 

-pli $VERA_HOME/ lib/ veriuser .so 

2.6 Running the Vera Stand-Alone Simulator 

Vera can be used by itself as a concurrent programing language. As such, it is a cycle-based simulator, 
which can run Vera models stand-alone or linked with additional C models. The pre-compiled copy of 
this simulator is in $VERA/home/binA?erajcs. If you want to link in your own C code to this simulator, 
instead of using the pre-compiled copy above, you must compile verajuserx and link it with 
$VERA_HOME/lib/libVERA.a. Additionally, if you are using a Solaris platform you must link in 
-Isocket -Insl -lintl along with any other appropriate libraries. See Section 18.8, Running Vera Stand- 
alone" for usage of the resulting simulator. 



Note - If you do not use Verilog-XL and do not have the veriuser.h file 
available, you must define "NO_VERILOG_SIM" from the command line 
when you compile verajuserx. 
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2.7 Testing the Installation 

Make sure that the Verilog executable in your path is called verilog and that it is linked with the 
Vera tasks. In $VERAJiOME/samples there are complete examples, each with a doit script. To test 
the installation, check that the scripts compile the tests and run Vera with Verilog. 



2.8 Vera Support 

Please use the following email addresses for Vera-related issues: 

Technical Issues: 

Customer Support (setup, bugs, help): vera-support@synopsys.com 

Enhancement Requests: vera-enhance@synopsys.com 

Documentation Issues: vera-doc@synopsys.com 

Other Feedback: vera-feedback@synopsys.com 

Information, Sales, and Licensing: 
Licensing: vera-Hcense@synopsys.com 

Sales Information: vera-sales@synopsys.com 
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3. Vera-HVL: The Language 

This chapter describes the basics of Vera-HVL. It introduces the lexical conventions and.some 
of the basic components of the language. It has these sections: 

• Lexical Conventions 

• Data Types and Variable Declaration 

• Arrays 

• Strings 

• Enumerated Types 

• Vera Operators 

• Variable Assignment 

3.1 Lexical Conventions 

Vera-HVL source code consists of a stream of lexical elements. The types of lexical elements 
are: 

• White space 

• Comments 

• Statement Blocks 

• Identifiers and Keywords 

• Strings 

• Numbers 

3.1-1 White Space 

White space is any sequence of spaces, tabs, newlines, and formfeeds. White space is used in 
Vera as token separators. Whitespace can be used freely and is ignored by Vera, except within 
a string. 

3-1.2 Comments 

Vera supports two forms of comments: a one-line comment and a block comment 

A one-line comment starts with a double slash (//) and finishes out the line. The syntax is: 

any_yera_s ta temen t ; // One line comment. 

A block statement starts with a /• and ends with a */. Everything between the start and end 
tags is a comment The syntax is: ; * 
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/* Blocks of comments 
can take up 
multiple lines */ 



Note - Block comments cannot be nested. 



3.1.3 Statement Blocks 

Vera supports three methods of creating statement blocks: begin/end, braces, and fork/join. 

The syntax for begin/end statement blocks is: 

begin 

vara_s ta temen ts 

end 

The syntax for statement blocks using braces is: 
{ 

vera_s ta temen ts 

; 

The syntax for fork/join statement blocks is: 

fork 

processl () ; 
process 2 () ; 

processNO ; 
join 

Forks and joins are discussed in more detail in Section 6.1, "Fork and Join." 

3.1.4 Identifiers and Keywords 

An identifier is a sequence of letters {a-zA-Z], digits[0-9] and underscores!.]- Identifiers are 
case-sensitive and cannot begin with a digit 

In addition to the Vera keywords, all signal types should be considered keywords. Table 3-1 
lists the Vera signal types. 

Table 3-1 Vera Signal Types 



ASYNC 


CLOCK 


NDRIVE 


NHOLD 


NRX 


NRZ 


NRO 


NR1 


NS AMPLE 


PDRIVE 


PHOLD 


P RX . 


PRZ 


PRO 


PR1 


PS AMPLE 
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Vera also uses a set of predefined q_values with its Value Change Alert implementation 
(Section 4.4,5, "Value Change Alert (VCA)"). Table 3-2 lists the predefined q_values. 



Table 3-2 VCA q.values 



gnr 






6 12 




giO 


nr 


rx 


rz 


r0 


rl 




snr 


srx 


srz 


szO 




srl 





Vera has several predefined system functions and system tasks whose names must not be used 
as program identifiers. Table 3-3 lists the predefined identifiers. 



Table 3-3 Vera Predefined System Functions and Tasks 



alloc 


call_func 


calLtask 


cast.assign 


dose_conn 


delay 


error 


error_mode 


exit 


fdose 


fflush 


flag 


fopen 


fprintf 


freadb 


freadh 


freadstr 


get.bind 


get_bind_id 


get_conn_err 


get.cyde 


get_plus_arg 


get.systime 


get_time 


mailbox_receive 


mailbox.send 


make_client 


make_server 


printf 


rand48 


random 


region_enter 


region.exit 


rewind 


semaphore_get 


semaphore, 
put 


sprintf 


sscanf 


stop 


sync 


timeout 


trace 


trigger 


unit_delay 


up.connections 


urand48 


urandom 


vsv_call_func 


vsv_call_task 


vsv_dose_conn 


vsv_get_con_ 
err 


vsv_make_ 
client 


vsv_make_server 


vsv_up_ 
connections 


vsv_wait_for_done 


vsv_wait_for_ 


wait_child 


wait_var 







input 
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Vera has several predefined system macro constants whose names must not be used or rede- 
fined without proper system tasks. Table 3-4 lists the predefined constant identifiers. 



Table 3-4 Vera Predefined Constants 



stderr 


stdin 


stdout 


ALL 


ANY 


BAD.STATE 


BADJTRANS 


CHECK 


CHGEDGE 


CLEAR 


CROSS 


CROSS.TRANS 


DEBUG 


DELETE 


EC.ARRAYX 


EC_CODE_END 


EC.CONFUCT 


EC.EXPECT 


EC_FULLEXPECT 


EC.MBXTMOUT 


EC.NEXPECT 


EC.RETURN 


EC.RHNTMOUT 


EC.SCONFUCT 


EC.SEMTMOUT 


EC.SEXPECT 


EC.SFULLEXPECT 


EC.SNEXPECT 


ECJJSERSET 


EQ 


EVENT 


FIRST 




GOAL 


GT 


HAND.SHAKE 


HI 


HIGH 


HNUM 


LE 


uc.Exrr 


UC.PRERR 


UC.PRWARN 


UC.WAIT 


LO 


LOAD 


LOW 


LT 


MAILBOX 


NAME 


NEGEDGE 


NEXT 


NOJDVERLAP 


NO.WAIT 


NUM 


NUM_BIN 


OFF 


ON 


ONE.BLAST 


ONE.SHOT 


ORDER 


POSEDGE 


PROGRAM 


RAWIN 


REGION 


REPORT 


SAVE 


SEMAPHORE 


SET 


SILENT 


STATE 


STR 


STR_ERR_OUT_OF_ 
RANGE 


STR_ERR_REGEXP_ 
SYNTAX 


SUM 


TRANS 


VERBOSE 


WATT 







3.1.5 Strings 

A string is a sequence of characters enclosed by double quotes. A string must be contained in 
a single line unless the new line is immediately preceded by a back slash. In this case, the back 
slash and new line are ignored. 



3.1.6 Numbers 

In Vera, a number can be formed using either the LITJNTEGER or NUMBER format. 

The iiIT_lNTEGER format is a simple decimal number specified as a sequence of digits from 0 
to 9. Negative signs are allowed to specify negative integers. Underscores are ignored and 
may be used for clarity: The syntax is: 
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[0123456789]+ 
The NUMBER format takes these forms: 

<sxze> ' <hasexnusiber> 

<size> - The <size> specifies the number of bits in the number. The size upper limit is 
dependent on the host machine, but it is generally 32 bits. If the <siie> is omitted, the 
number of bits for <number> defaults to the host machine word size. A plus or minus sign 
before the <size> specification signifies the number's polarity. 

<base> - The <base> is always preceded by a single quote (0. The <base> can be one of the 
following: d(ecimal), hexadecimal), o(ctal), or b(inary). The base identifier can be either 
upper or lower case. 

<number> - The valid elements of <number> for each <base> are: 

'b (binary): [01xXzZ_] 

'd (decimal): [0123456789_J 

'o (octal): [01234567xXzZ_] 

'h (hexadecimal) : [0123456789abcdefABCDEFxXzZ_] 

X and x represent unknown values, and Z and z represent high impedance values in 
binary, octal, or hexadecimal form. Underscores are ignored. 

If the most significant specified digit of a <number> representation is an x or a z, the Vera com- 
piler extends the x or z to fill the higher order bits or digits. For example, 8T>x means 
8 *h xxxxxxxx, or 8T)zOO means S'bzzzzzzOO. 



3.2 Data Types and Variable Declaration 

Vera's basic data types are integers, bits, strings, events, bind.var, classes, and enumerated 
types. You can also make composite types of the base types with arrays, associative arrays, 
and records. 

Variables are seen globally if they are declared at the top (program) level. If they are declared 
in blocks (begin/end, {J. fork/join), they are seen locally. 

3-2.1 Integers 

Integers are signed variables. They can have integral values between 1-2 31 and 2 31 -!. An inte- 
ger may become X (unknown) when it is not initialized or when an undefined value is stored. 

The syntax to declare an integer is: 

integer variable^xiame = initial_value; 
The initialization is optional in the variable declaration. _ 
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Note - For expressions involving both bit and integer types, the 
integer types are first converted to 32-bit unsigned integers. 



3.2.2 



Bits 



Bits can have the value 0 (logic 0), 1 (logic 1), z (high impedance), or x (unknown). 



The syntax to declare a bit is: 



bit variable_xxame ~ initial_value; 



The initialization is optional in the variable declaration. 

Vera also supports bit fields. The syntax to declare a bit field is: 

bit [high: low] variable^name = initial^value; 

High specifies the upper limit on the field, and low specifies the lower limit on the field. The 
maximum size of a bit field is 4095 bits. When declaring bit fields, you cannot use variables for 
high and low specifiers. 

Vera also supports registers. Registers in Vera are identical to bit vectors. The syntax to declare 
a register is: 

reg [high: low] variable__name = initial_value; 

3.2.3 Strings 

Strings are character data types that have a wide range of operators associated with them for 
manipulating characters. 

The syntax to declare a string is: 

string variable_name = initial_value; 

The initialization is optional in the variable declaration. 

Strings and string operators are discussed in more detail in Section 3.4, "Strings." 



Bind.var variables hold binds. Binds are used to group and associate signals with ports. 
Bind_vars are used with task calls to specify which port the task call communicates with 
more information concerning binds, see Section 433, "Bind." 

The syntax to declare a bind_var is: 

bind_var vari ahl e_uame = initial^value; 



3.2.4 



Bind vars 
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The initialization is optional in the variable declaration. 

Bind.vars are discussed in more detail in Section 43.4.1, "bindjvar Variables." 

3.2.5 Events 

Events are variable types used to manage triggers. They exist in one of three states: OFF, ON, 
and null. Events are passed as arguments to task, function, and method calls to specify the 
tngger point. They are used mainly to synchronize concurrent processes. Synchronization and 
the use of events is discussed in more detail in Section 6.2, "Events." 

The syntax to declare an event is: 

event variabl e_name «= initial_value; 

The default initial joalue is OFF. You can only initialize events to null, which has the effect of 
the trigger always being ON. 

3.2.6 Enumerated Types 

Enumerated types are named integer constants. The syntax to declare an enumerated type is: 
enua category = list; 

or ' 

enum category {list} 

The category is the name of the enumerated type. It is used to assign list values to variables. 

List is a list of category values separated by commas. They are assigned sequential integer. val- 
ues in the order listed. 

Enumerated types are discussed in more detail in Section 35, "Enumerated Types." 

3.2.7 cast_assignO 

Vera provides the cast_assignO system function to assign values to variables that might not 
ordinarily be valid because of typing. The syntax for cast.assignO is: 

c&st_*Mign(dest:_var, source_exp t, check}); 

destjvar - The destjoar is the variable to which the assignment is made. It can be any 

non-array scalar type (bits, integers, strings, enumerated types, bind.vars, port variables, 
events, and object handles). 

source jexp - The source jexp is the source expression that is assigned to the destination 
variable. 
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check - The check modifier can optionally be specified using CHECK. Its use determines how 
the function handles invalid assignments. 

When the cast_assignO system function is called without the CHECK modifier, the function 
assigns the source expression to the destination variable. If the assignment is illegal, a fatal 
runtime error occurs. When the cast.assignO system function is called with the CHECK mod- 
ifier, the function makes the assignment and returns a 1 if the casting is successful, or it does 
not make the assignment and returns a 0 if the casting is unsuccessful. In the latter case, no 
runtime error occurs, and the destination variable is set to NULL, X, or uninitialized, depend- 
ing on the data type. 

Note - The compiler only checks that the destination variable and 
source expression are scalars. Otherwise, no type checking is done at 
compile time. 

These are examples of the cast.assignO system function: 

cast_assign(my_enum, 12*7); 

cast_ assign(my_portvar, my_bindvar) ; 

The first example assigns the expression to the enumerated type. Without cast_assignO, this 
assignment is not allowed because of strong typing of enumerated types. The second example 
assigns the value of the bind_var to the port variable. Again, this assignment is not possible 
without cast_assign() because of strong typing of port variables. 

A discussion of the cast_assign() system function and its use with objects is in Section 8.12, 
"Casting." 



3.3 Arrays 



Vera supports one-dimensional arrays, which are lists of variables that are all of the same type 
and called with the same name. Arrays in Vera can be static (global) or dynamic (local). You 
can also create associative arrays that have the advantage that each entry of the array gets al- 
located only when it is accessed. 

3.3.1 Arrays 

Any variable type can be declared as an array. The syntax to declare arrays is: 

integer array_name[size] ; 
bit [high: low] array_name[size] ; 
bin<a_var array_name[size] ; 
event array_name {size); 
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size - The size specifies the number of elements in the array. The maximum number of 
elements in an array is 2 AA 31-1 elements. For larger arrays, you should use associative 
arrays. 

Accessing an array with an unknown bit (V) in the index causes a simulation error. Also, 
writes to an array with an unknown in the index are ignored, and reads with an unknown in 
the index return *X's. 

Note that a bit field of an array element cannot be referenced directly. To reference a bit field 
of an array element, use a temporary variable. For example: 

tmp = memory [42] ; 

if <tmp[3:2] == 0) ... 

You cannot initialize an array in the declaration. 



3.3.2 Associative Arrays 

Associative arrays are arrays whose dimensions are not specified. The syntax to declare asso- 
ciative arrays is: 

integer array^name [ 3 ; 
bit [high: low) array_name [ ] ; 
bind_vax array_name [ ] ; 
event array^name [ ] ; 

Array elements in associative arrays are allocated dynamically, when you access a particular 
address. The array index tracks those elements that have been assigned values and stores 
those values within the array. When using integer and bit associative arrays, if you try to ac- 
cess an element that has not been assigned a value, an 'X' is returned. When using bind.var 
and event associative arrays, if you try to access an element that has not been assigned a val- 
ue, a NULL value is returned. 

Note - Using associative arrays slows down simulation time slightly, 
though the effect is usually unnoticeable. 

Vera supports several mechanisms for analyzing associative arrays: 

es0oc_index (CHECK, array_name. index) ; 
a«»oc_index (DELETE, &rray_name , index) ; 

The array jname is the name of associate array you are analyzing. - 

The index is the numerical index of the element you are analyzing. 

The CHECK function checks if an element exists at the specified index within the array. If it 
does, a 1 is returned. If it does not, a 0 is returned. 
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The DELETE function deletes the element specified at the specified index. If it is successful, a 
1 is returned. If the element does not exist a 0 is returned. 

Vera supports two additional functions used with associative arrays: 

assoc.lndex (FIRST, array_name t index^yar) ; 
aeeoc_index (NEXT, array_name, index. var) ; 

When the FIRST keyword is used, the function returns the element associated with the first 
valid index. The index joar is assigned the value of the first valid element in the array. The 
function returns a 1 if it is successful and a 0 if it fails. 

When the NEXT keyword is used, the function returns the element associated with the next 
valid index. The indexjoar is assigned the value of the next valid element in the array. The 
function returns a 1 if it is successful and a 0 if it fails. 

3.4 Strings 

Within Vera, string data types are defined as classes. Vera also defines a set of internal vari- 
ables and class methods used to analyze and manipulate strings. 

3.4.1 Printing Strings 

Vera strings are printed using the C-style printf function. The syntax to print a string is: 

printf ( "string^ format* , variables) ; 
Vera uses several predefined format specifiers. Table 3-5 lists Vera's format specifiers. 



Table 3-5 Vera's Format Specifiers 



Format Specifier Format 



%d or %D a decimal number 

%h or %H or %x or %X a hexadecimal number 

%o or %0 a octal number 

%b or %B a binary number 

%c or %C a single character 

%sor%S a string 



The format specifiers are: %d or %D (decimal), %h or %H or %x or %X (hexadecimal), %o or 
%0 (octal), %b or %B (binary). You can also use %s or %S to read in a string, or %c or %C to 
read in a single character. 
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By placing a number before the format specifier, you can specify how many digits are read in 
a particular number. If you want to minimize field width, use a 0 before the format specifier. 

You can also use escape characters for formatting. Table 3-6 lists the Vera escape characters. 



Table 3-6 Vera Escape Characters 



Escape String 


Character Produced 


\n 


new line 


\t 


tab 


\\ 


\ 


\" 




\ddd 


. a character specified in 1 to 3 octal digits 


%%* 


% 



3.4.2 Valid Operators 

Vera provides a set of operators that can be used to manipulate combinations of string vari- 
ables and string constants. Table 3-7 lists the valid operators. 



Table 3-7 Valid Operators 



Operator 


Meaning 




Check equality of two strings 


!= 


Check inequality of two strings 


\strlftr2..} 


Generate a concatenated string with strl, $tr2, ... 


{num{str)} 


Generate a string duplicated num times. 



Note - You can compare string variables to nulL 



3.4.3 String Class Methods 

Vera's string functions behave as class methods. Therefore, the string being analyzed must 
specified in the method call. The syntax to make method calls is: 

s tring_name . function ( ) 

stringjname - The string jname is the string that is the target of the method call. 

function - The function is the name of the method being called. 




Synopsys Inc. 



52 Chapter 3. Vera-H VL: The Language 



Vera 4.0 User's Manual 



3.4.3.1 General String Class Methods 

Vera provides a set of general functions (or methods) to handle hidden values within string 
variables. 



lenO 

The len() function returns the length of the string as an integer. The syntax is: 

s tring^name . lea ( ) ; 
For example: 

string str; 

str = "This is a string*; 

printf ("String length = %0d\n*, str.lenO); 
This example prints the string length of string str. 

getcO 

The getc() function returns a character at a specified location. The syntax is: 

string_name .Qetc (i) ; 
i - The f parameter must be an integer value. 

The function returns the character specified by L If the parameter is larger than the given 
string, 0 is returned. 

For example: 

string str = "This is a string*; 

printf CThe fifth character is %c\n*, str.getc(5)) ; 
This example prints the fifth character in string sfr.is a bit function that 

putcO 

The putcO task assigns a given character to a specified location. The syntax is: 

s tring_name . putc ( i , * char" ) ; 
i - The i parameter must be an integer value. 
char - The char parameter must be a bit 

The task stores char in the i position within the string. If i is larger than the string, char is ig- 
nored and the internal flag STR_ERR_OUT_OF_RANGE is set 

For example: 



string str = m X23456789*; 
str.putc(0, m l m ); 
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This example sets string str to "123456789". 
get.statusO 

The get_statusO function returns the current status flag value as an integer. The syntax is: 

s tring_name . get_atatus ( ) ; 

The possible values are 1, which corresponds to STO_ERR_OUT_OF_RANGE (set by putc), 
and 2, which corresponds to STR_ERR_REGEXP_SYNTAX (set by match). If there is no flag, 
the function returns a 0. 

get_status_msgO 

The get_status_msgO function returns a string describing the current status flag value. The 
syntax is: 

s tring_name . get_c tatus_xnsg ( ) ; 

The function returns the string STR_ERR_OUT_OF_RANGE (set by putc) or 
STR_ERR_REGEXP_SYNTAX (set by match). 

substrO 

The substrO function returns the sub-string of characters between two specified locations. The 
syntax is: 

strijig_name.*ub«tr (i, j) ; 
i - The i parameter is the first location in the string. 
/ - The j parameter is the second location in the string. 

The function prints the characters between the locations, inclusively. If the second argument is 
omitted, the function returns all characters from the first location to the, end of the string. 

For example: 

string str, strl; 

str = •ABCDEF%- . 
strl = str.substr (2,4) ; 

This example assigns string strl the value "CDE". 

— ■ ■ ■ «•—. ■. 

3.4,4 String Class Methods for Matching Patterns 

Vera provides several class methods used to match patterns within strings. 
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searchO 

The search function searches for a pattern in the string and returns the integer index to the be- 
ginning of the pattern. The syntax is: 

s tring_name . sear ch (pa 1 1 era ) ; 
pattern - The pattern parameter must be a string. 

The function returns the index value at the start of the string pattern. If the pattern is not 
found, the function returns -1. 

For example: 
integer i ; 

string str = "This is a test*; 
i = str .search ( *his*) ; 

This example assigns the index 1 to integer i. 
matchO 

The matchO function processes a regular expression pattern match. The syntax is: 

s t ring_name. match (pat tern) ; 
pattern - The pattern parameter must be a string. 

The function returns a 1 if the expression is found, and a -1 if the expression is not found. If 
there is a syntax error in the regular expression, the function returns 0 and sets the status to 
STR_ERR_REGEXP_SYNTAX. 

For example: 

integer i; 
string str; 

str = "1234 is a number.*; 
i = str .match ( *is*) ; 

This example assigns the value 1 to integer i because the pattern "is" exists within string str. 

The following functions (prematch, postmatch, thismatch, and backref) are used to access the 
match strings. 

prematchO 

The prematchO function returns the string before a match, based on the result of the last 
matchO function calL The syntax is: 

s tring^naxne . prematch ( ) ; 
For example: 
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integer i ; 

string str, strl; 

str = *1234 is a number.*; 

i = str.match( w is*) ; 

strl = str.prematchO ; 

This example assigns the value "1234 " to string strl. 
postmatchO 

The postmatchO function returns the string after a match, based on the result of the last 
matchO function call. Hie syntax is: 

s tring^name . postmat ch ( ) ; 

For example: 

integer i ; 

string str, strl; 

str = m 1234 is a number.*; 

i = str. match ( m is* ) ; 

strl = str.postmatchO ; 

This example assigns the value * a number." to string strl. 
thismatchO 

The thismatchO function returns the matched string, based on the result of the last matchO 
function call. The syntax is: 

s tring_najne . thismatch ( ) ; 

For example: 

integer i; 

string str, strl; 

str = *1234 is a number.* 

i = str.matchCis*) ; 

strl = str. thismatchO ; 

This example assigns the value "is" to string sfrl. 
backrefO 

The backrefO function returns matched patterns, based on the last matchO function call. The 
syntax is: 

s tring_name . b&ckraf ( index) ; 

index - The index is the integer number of the Perl expression being matched. Indexing starts 
at 0. 
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This function matches a string with Perl expressions specified in a second string. For example: 
integer i; 

string str, patt, strl, str2; 

str = *1234 is a number. * 

patt = Mf0-9]+) ([a-zA-Z .]+)•; 

i = str .match (patt) ; 

strl = str.backref (0) ; 

str2 = str.backref (1) ; 

This example checks the Perl expressions given by string patt with string str. It assigns the val- 
ue "1234" to string strl because of the match to the expression "(0-9]+". It assigns the value "is 
a number." to string sfr2 because of the match to the expression "[a-zA-Z .]+". Any number of 
additional Perl expressions can be listed in the patt definition, and then called using sequential 
index numbers with the backrefO function. 

3.4.5 String Class Methods for Type Conversion 

Vera provides several class methods used for type conversion. 
atoiO 

The atoiO function handles a string as an ascii number and converts it to an integer The syn- 
tax is: 

s tring_name . atoi ( ) ; 

The string must be an ascii number. Underscores are ignored. Spaces and all characters other 
than digits are invalid. If the ascii string is not a number representation, the function returns 0. 

For example: 

integer i; ' 
string str; 
str = *123*; 
i = str.atoiO; 

This example converts the ascii text "123" and assigns the value 123 to integer i. 
ftoaO 

The itoaO function converts an integer to an ascii number in a string. The syntax is: 

s tring^name . ito* ( i ) ; 

i - The parameter i must be an integer. Underscores are ignored. All other characters are 
invalid. 



For example:. 
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string str ; 
str.itoa(456) ; 

This example converts the numeric string value of 456 to ascii text and assigns the value "456" 
to string str. 

atohexO 

The atohexO function handles a string as an ascii hexadecimal number and converts it to a bit 
value. The syntax is: 

s tring^name . atohex ( ) ; 
For example: 

bit [127:0] b; 
string str; 
str = *'hl2-; 
b = str .atohexO ; 

This example converts the ascii text value " / hl2" to the hexadecimal number 1\12 and assigns 
it to bit b. 

atooctO 

The atooctO function handles a string as an ascii octal number and converts it to a bit value. 
The syntax is: 

string_najne.atooct ( ) ; 

For example: 

bit [127:0] b; , 

string str; 

str = • # ol2*; 

b = str.atooct 0 ; 

- "... * r ". } 

This example converts the ascii text value "ol2" to the octal number 'ol2 and assigns it to bit 
b. 

atobinO 

The atobinO function handles a string as an ascii binary number and converts it to a bit value. 
The syntax is: 

s tring^name . atobin ( ) ; 

For example: 
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bit [127:0] b; 
string str; 
str = *'b01*; 
b = str .atobin ( ) ; 

This example converts the ascii text value '"bOl" to the binary number 1)01 and assigns it to 
bit &. 

bittostrO 

The bittostrO function converts the text in bits to text in strings. The syntax is: 

string_name. bittootr (bit [high: low) bit_string) ; 
For example: 

bit [127:0] b; 
string str; 
b = "Hello* ; 
str.bittostr (b) ; 

This example converts the bit string "Hello" to a string and assigns the value "Hello" to string 
str. 

3.4.6 Additional System Functions 

The following system functions are not part of the string class methods. They are independent 
functions that manipulate strings or are related to strings. 

sprintfO 

The sprintfO system task sends output to a string variable. The syntax is: 

■print f {string__name, string^ format) ; 
The output specified by string Jormat is assigned to the string string jname. 
For example: 

string SO; 
string str; 
SO =. -SO stringr*; 
sprintf(str, -SO is %s\n', SO); 

This example assigns the string "SO is SO string" to string str. 
sscanfO 

The sscanf 0 system task reads input from a string. The syntax is: 
m*c*n£(string_name t string^ format) ; 
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The input specified by string Jormat is assigned to the string string jname. 

For example: 

string si; 

int il, i2, i3; 

si = m 123 'hlO 4567-; 

sscanf(sl, * %d %h %2d', il, i2, i3); 

This example assigns the values 123, 16, and 45 to the variables il, il, and i3 respectively. 

3.5 Enumerated Types 

Enumerated types are a user-defined list of named integer constants. As discussed in 
Section 3.2.6, the syntax to declare an enumerated type is: 

enum category = list; 

So, for example, we could have: 

enum colors = red, green, blue, yellow, white, black; 

This operation assigns a unique number to each of the color identifiers and allows us to create 
a new data type of type "colors." 

colors new_color ; 
integer val; 

new__color = green; 

new_color =1; // Invalid assignment. 

This example assigns the color green to the colors variable newjcolor. The second assignment is 
invalid because of the strict typing rules used by enumerated types. 

Elements within enumerated type definitions are assigned identifiers, which are numbered 
consecutively, starting from 0. In our example, red is assigned 0, green is assigned 1, and so 
on. 

; You can further specify identifiers in the element list in several ways: 

• name This associates the next consecutive integer with name. 

• ,name[N] This generates N names in the sequence (nameO, namel, 

nameN-1) where N must be a constant integer. 

• name[rnn] This creates a sequence of names starting with namen and 

counting up (or down) to namem. 

• name=N This assigns the constant N to name. 

For example: 

enum instructions = add=10, sub[5], jmp[6:81; 
Synopsyslnc. 
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This example assigns the number 10 to the enumerated type add. It also creates the enumerat- 
ed types subO, subl, subl, sub3, and sub4, and assigns them the values 0-4 respectively. Finally, 
the example also creates the enumerated types jmp6,jmp7 t and }mp8, and assigns them the val- 
ues 6-8 respectively 

3.5.1 Enumerated Types in Numerical Expressions 

Elements of an enumerated type or an enumerated type variable can be used in numerical ex- 
pressions. The value used in the expression is the numerical value assigned to the enumerated 
type element For example: 

colors new_color; 
integer vail, val2; 

vail = blue * 3; 

new_color = yellow; 

val2 = new_color + green; 

From our previous declaration, blue has a numerical identifier of 2. This example assigns vail 
a value of 6 (2*3). This example then assigns val2 a value of 5 (2+3). 



Note - Assignments to enumerated type variables are strongly typed. 
Thus, assigning numerical expressions to enumerated type variables 
causes compilation errors. 



3.5.2 Increment and Decrement Operations on Enumerated Types 

The operators ++, — , +=, and -= have special meanings on enumerated type variables. 

enum var ++ Assigns the next member (as defined by the definition order) to 

enumjoar. The first member is selected if enumjoar is currently holding 
the last member. ... 



enumjoar— 



enum var += val 



enumjoar -= val 



Assigns the previous member (as defined by the definition order) to 
enumjoar. The last member is selected if enumjoar is currently holding 
the first member- 
Assigns the val-th next member to enumjoar. A wrap to the beginning 
of the list occurs when the end of the list is reached. 

Assigns the val-th previous member to enumjoar. A wrap to the end 
of the list occurs when the beginning of the list is reached. 
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Note - "enumjoar += valf is different than 44 enumjoar = enumjoar + 
valf The former is legal while the latter is illegal because 44 enumjoar + 
val" is evaluated to a numerical expression which, in turn, cannot be 
assigned to an enumerated type variable. 



3.6 Vera Operators 

Vera uses a set of standard operators for expressions and concatenation. 

3.6.1 Operators 

Table 3-8 lists the basic Vera operators. 



Table B-8 Vera Operators 



Operator 


Semantics 


0 


concatenation 


'O 


concatenation left of assignment 


+ -•/ 


arithmetic 


% 


modulus 


>>=<<= 


relational 


i 


logical negation 




logical and 


1 1 


logical or 




logical equality 


!= 


logical inequality 




case equality 




case inequality 


=?= 


wild equality 


!?= 


wild inequality 




bit wise negation 


& 


bit wise and 


&- 


bit wise nand 


1 


bit wise or 


1- 


bit wise nor 


A 


bit wise exclusive or 
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Operator Semantics (Continued) 

~- bit wise exclusive nor 

& unary and 

~&c unary nand 

I unary or 

- 1 unary nor 

A unary exclusive or 

~ A unary exclusive nor 

« left shift 

» right shift 

?: conditional 



The conditional operator (?:) and the comparison operators ==, !=, ===, and !== can be used to 
compare variables of the same type for all base types. 

The wild equality operator (=?=) treats an x value or z value in a given bit position (for bit val- 
ues) as a wildcard. It matches any bit value (0, 1, z, or x) in the value of the expression being 
compared against it. Consider the following vector and some comparisons against it: 

a = 8'b00110101 

(a =?= 8'b00110101) is true 
<a =?= 8'b00010101) is false 
(a =?= 8'b00xl0101) is true 

The same rule applies to the wild inequality operator(!?=). 

The precedence order of binary operators is defined in Table 3-9. 

Table 3-9 Precedence Order of Binary Operators 

Operator Precedence 

! - Highest precedence 

*/% 
+ - 

« » 
<<=>>= 
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Operator 



Precedence 



I I 



?: 



Lowest precedence 



3.6.2 



Concatenation 



The syntax for concatenation is: 



variable = {varl, var2, — , varN); 
Variable is the result of the concatenation. The arguments are concatenated sequentially. 
For example: 

bit {6:0] data; 

bit parity; 

bit [7:0] foo; 

foo = {data, parity); 

Multiple concatenation is also supported. For example: 

{ 32 {l'bl ) } 
{ 4 {foo, moo) } 

This example concatenates foo and moo four times. 

Vera uses the left brace to open a block and also for concatenation. This creates a conflict when 
using the left brace for concatenation on the left-hand side of assignments; Therefore, Vera 
uses a single quote to prefix the left brace when it is used for concatenation on the left For ex- 



ample: 



•{data, packet, parity) = 256 'b0; 



3.7 Variable Assignment 

The variable assignment is the primitive operation to set a value for a variable. The syntax to 
assign values to variables is: 



vari abl e_name operator assign_expression 



For example: 
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i = 0; 
a = 1'bO 

temp[3:0] = 4'bl000; 
memory (533 = 8'b0x0x0x0x; 
b_port = portid ? portO : portl ; 

There are two types of assign operators: the = operator is called the simple assignment opera- 
tor; all others are called compound assignment operators. 

For the compound assignment operator, the expression a <operator>= b is equivalent to 
a = a <operator> b. 

For example, the following are equivalent 

i = i + 5; 
i += 5; 

Vera supports the C-style ++ and — operators. For example: 

result =5; 

a = result++; ( 

a = ++result; 

The second line accesses the variable and then increments in. The third line increments the 
variable and then accesses it. 

Vera does not support assignment recursion. The following is an illegal assignment: 
a = b = c; 

The Vera compiler does type checking. Bind_yar variables can be used in simple assignments 
through the assignment operator, can be used in conditional assignments (?:), or can be passed 
as arguments. Event variables cannot be used in assignments because they are used only for 
triggering purposes. All other combinations of integer and bit variables are valid. 



Note - To help avoid mistakes, <assignments> are not expressions. 
Hence, statements like the following are invalid: 

if(a=b) a=c+d; // should be a==b * * 

while (a=b) a=random(); // should be a==b 
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4. Basic Vera Programming 

This chapter documents the basic elements of Vera programming. It details the fundamental program 
" structure used in all Vera programs, introduces signal interfaces, and describes several of the elementary 
signal operations. This chapter includes these sections: 

• Vera Programming Overview 

• Program Structure 

• Signal Declarations 

• Signal Operation 

• Asynchronous Operations 

• Subroutines 



4.1 Vera Programming Overview 

Vera programming involves the integration of several key components of a Vera testbench: the main 
Vera program, the Vera-HDL interface, the clocking mechanisms, signal operations, and Vera subrou- 
tines. 

The main Vera program is where global variables are defined, executable statements are carried out, and 
calls to subroutines are made. The main Vera program is the centerpiece of the Vera testbench. 

The Vera-HDL interface defines how Vera interacts with the hardware description created in either Ver- 
ilog or VHDL. It establishes how the HDL signals are driven and sampled by Vera. 

The clocking mechanisms determine the timing of the HDL signals. This directly affects signal driving 
and sampling. The clocks also determine timing for Vera processes, which affects synchronization of 
concurrent threads. ' 

The signal operations include the driving and sampling primitives in the Vera language. They handle all 
sampling and driving of signals. Other fundamental signal operators include the expect primitive and 
synchronization. ..... 

Vera can call subroutines (tasks and functions) from the main Vera program and from within subrou- 
tines. These subroutines include pre-defined tasks and functions as well as user-defined tasks and func- 
tions. 
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4.2 Program Structure 



Vera programs have a single, top-level structure denoted by the keyword program. The syntax is: 

# include <vera_def inos . vrh> 
tinclude * filename* 
# define text_macro 
ipreprocessor commands 

si gna l_decl ara ti ons ; 
coverage^blocks ; 

externa 2_ subrou tine__declara ti ons ; 

subroutines ; 

classes; 

HDL_and_C_subrou tines ; 

program program^name 
{ 

vari abl e_decl ara tion; 
top_level_code; 



The top block contains tasks, procedures, and function definitions. Vera, like C, supports two levels of 
hierarchy: top (containing the program statement) and others. Variables defined in the top block are 
global and are seen in any task/procedure/function anywhere in the entire set of testbench files (unless 
the same name is used to define a local variable). Using same named variables is called "shadowing" 
and should be used with caution because of variable conflicts that can arise. 

The syntax of a complete Vera testbench is flexible. It has one program and any number of submodules 
in any order. Forward references are allowed in any file. However, references to tasks or functions in 
other files require external references to be declared. The compiler accepts task and function declara- 
tions before and after the top program. 

Submodules, declarations, and external declarations are discussed in more detail in subsequent chapters. 
Note, however, that they can be used in any order. 

File inclusion, text macros, and preprocessor commands are discussed in Section 18.2, "Preprocessor." 
Coverage blocks are discussed in Chapter 11., "Functional Coverage." Classes are discussed in 
Section 8.1, "Classes and Objects.** HDL and C/C++ subroutines are discussed in Chapter 14, "Vera- 
HDL Task Calls" and Chapter 15, "Calling C/C++ Functions." 

The other major components of the main Vera program are discussed in detail in subsequent sections in 
this chapter. 



} 
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4.3 Signal Declarations 

Vera signal declarations determine how Vera testbenches are connected to HDL designs. There are three 
methods of signal declaration: Vera-HDL interface specifications, virtual port definitions, and signal 
binds. 



4.3.1 Vera-HDL Interface Specifications 

The Vera-HDL interface identifies a set of signals through which Vera communicates with the HDL en- 
vironment The interface also determines how Vera drives and samples those signals. Finally, the inter- 
face defines the clock to which the signals are tied. The syntax for interface specifications is: 

interface interface^name { 

signal^direction signal^width signal_name signal_type skew; 

) 

signal jdirection - The signaljdirection specifies the direction of the signal with respect to Vera. 
It must be input, which specifies signals that go from the HDL to Vera, output, which specifies 
signals that go from Vera to the HDL, or inout, which specifies bidirectional signals. 

signal_width - The signal_width is a bit vector specifying the width of the signal. It must be in the form 
[highiO]. 

signaljname - The signaljname identifies the signal being defined. It is the top-level name of the HDL 
signal being connected. 

signal Jtype - The valid signal types and their definitions are listed in Table 4-1. 



Table 41 


Signal types 


Signal Type 


Operation 


NHOLD 


Output is driven on the negative edge of the interface clock. 


PHOLD 


Output is driven on the positive edge of the interface clock. 


NR value 


Output is driven on the falling edge of the interface clock for 1 cycle. 




Then it returns to value, which can be 0, 1, X, or Z. 


PR value 


Output is driven on the rising edge of the interface clock for 1 cycle. 




Then it returns to value* which can be 0, 1, X, or Z. 


NSAMPLE 


Input is sampled (evaluated) at the negative edge of the interface clock. 


PS AMPLE 


Input is sampled (evaluated) at the positive edge of the interface clock. 


CLOCK 


Specifies the clock, which qualifies other interface signals. 



For one-direction signals, only one signal type can be used. Input signals are sampled, and output 
: signals are driven. Multiple signal types should be associated with bidirectional signals. 

skew - The skew determines how long before or after the clock edge the signal is driven or sampled 
The skew must be in this format: 

— ^fcr 
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tvalue 

All drives are done at or after the appropriate clock edge (positive skew). This means that drives 
can only take positive skew values. All sampling is done at or before the appropriate clock edge 
(negative skew). This means that samples can only take negative skew values. This limitation so 
that causality is not violated; it is impossible to sample a signal, use the value to determine a drive, 
and then drive a signal on a single clock edge. 



Note - To avoid race conditions, you should use a skew of at least -1 for all 
signal sampling. 



Figure 4-1 shows an example of positive and negative skews. 



CLK1 









15 -10 

J L 




-20 

L 


25 


r 'i r 



[sample] [drive] [sample] [drive] 



Figure 4*1 Example of positive and negative skews 

This is an example interface declaration: 

interface arb { 

output (1:0] request PHOLD #1; 
input [1:0] grant PSAMPLE #-1; 
inout [7:0] data PSAMPLE #-1 PHOLD #1; 

> " : / ; ' 

4.3.1.1 HDL Nodes 

HDL nodes allow you to bind a Vera port directly with a wire or port in an HDL design. The syntax to 
declare an HDL node is: 

signal^direction signal_name signal _type skew node_method m signal_path m ; 

node_mcthod - The nodejtnethod specifies the type of HDL design you are linking to. It must be either 
verilog.node, which links to Verilog designs, or vhdl.node, which links to VHDL designs. 

signal _path - The signal jpath is the HDL path to the specified signal. It must be surrounded by double 
quotes. i. : 

Sy^iopsyelnc. 
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Note - VHDL nodes do not support signal subfielding. 



For example: 

inout [31:0] Dl PSAMPLE verilogjio'de ■ sys . cpu2 . pO_Dl • ; 
output req PSAMPLE vhdl_node • /sys/arb/pO_strb' ; 

Note the preceding slash and the use of slashes in the vhdI_node construct to specify the bierarchal 
path. 

When HDL nodes are used, the interface signals are declared as internal wires in the Vera-HDL shell 
iyerajshelt) and are directly connected to the specified HDL node. If all the signals are declared using 
the node construct, the vera_shell module has no input or output signals. It can then be included as a 
top module with the HDL design. As long as the interface does not change, the resulting verajshell- 
HDL module can be used with different test benches without redeclaring the signals. 

4.3.1.2 Clocking Domains 

Each interface defines a clock domain. The syntax to define a clock domain within the interface speci- 
fication is: 

Input clock_name CLOCK; 

clock_nome - The clockjname is the name of the HDL clock driving the simulation. 

The clock domain specifies when clock edges occur and determines when signals are driven and sam- 
pled. 

For a given interface specification, a clock domain establishes a relationship between the clock and 
when the other given interface signals are driven or sampled. 

Clock domains can be overlapped. The same signal can be associated with multiple clocks via multiple 
interface specifications. However, despite multiple interfaces, it is still a single signal and cannot be 
driven to two values at the same time. . 

4.3.1.3 Signal Depth 

Input signals are typically signalled in the current cycle. However, input signals can be sampled in pre- 
vious cycles. To reference a signal in a previous cycle, the signal depth must be specified in the signal 
declaration. The syntax to specify the signal depth is: 

signal^direction signal_name signal_type skew depth value; 

value - The value specifies the number of cycles that are stored for back-reference. If you want to 
reference a signal 3 cycles back, this value must be at least 3. The value must be an integer. 

For example: • u '.'"•*■ - 
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inout [7:03 data PSAMPLE PHOLD #1 depth 5; 
The syntax to reference a signal in a previous cycle is: 

Inter face^name . s ignal_name . N 
interface jname - The interface jname is the name of the interface in which the signal is defined. 
signaljiame - The signaljname is the name of the signal being referenced. 

N - N specifies how many previous cycles to look back when evaluating the signal. The current cycle is 
0, the previous cycle is 1, and so on. If no signal depth is specified, the default is the current cycle. 

4.3.2 Virtual Ports 

Virtual ports are sets of port signal names grouped together under a given name. Ports are defined out- 
side of the main program block. The syntax to define a virtual port is: 

port port_name {port_signall; port_sxgnal2; . . . ; port_signalN; } 
pori_nome - The port jname is the name of the virtual port you are creating. 

port_signalN - Port_signalN is a generic signal name that is assigned a specific HDL signal through a 
bind declaration. Multiple port signal names are separated by semi-colons (;). 

Virtual ports define a set of signal placeholders through generic signal names. The signal names must 
then be bound to the actual signals in the interface using a bind declaration. 

This is an example port declaration: 

port rcv__port {frame_n; valid_n; busy; packet ; } 

4.3.3 Bind 

Binds tie virtual ports to actual interface signals. Binds are declared outside of the main program block. 
The syntax to declare a bind is: 

bind port_name bincUname { 

port_signaW inter face_name. signaljname; 

} 

portjname - The portjname is the virtual port name you want to bind. 

bindjiame - The bind jname is the name of the bind you are creating. 

port_xignal_name - The portjsignalN is the name of the generic signal names that you are 

including in the bind Generally, all of the signals in the port are bound. However, you can bind 
only selected signals if you want. 

interface jtame - The interface jname is the name of the interface to which you are binding the port 
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signal jname - The signal jtiame is the name of the signal you are binding to the port. You can specify 
signal subfields using signaljiame[x:y\. 

Each bind in Vera is unique, and Vera assigns it a numeric ID. The bind can then be referred to by the 
name of the bind or by the numeric ID (obtained using the get J>ind_id0 system function). 

When using subfield binding, you can specify further subfields. For example: 

bind prt mybind{ 
a intf .sign[7:5] ; 

> . 
This example assigns a 3bit subfield to the port signal a. You can specify a subfield within that field as 
well: 

mybind.$aI2:l] 

This signal refers to the subfield in signal a, which corresponds to intf .sign[7:6]. 

This is an example bind using the port declaration from the previous section: 

bind rcv_port iport0{ 

frame_n router. frame_n0; 
validLn router ..valid_nO ; 
busy router.busy_nO; 
packet router. diO; 

} 

4.3.3.1 Bind Functions and Tasks 

Vera provides several system tasks and functions used with binds. 
get_bindO 

The get.bindO system function returns the current binding in a task or function. The syntax is: 

ff ot_bind(tI£>l); " • . ' 

ID - The ID can be either a numeric ID (obtained using the getJiindJdO system function), or it can be 

the string name of the bind. . .. v . . . 

The get bind JdO system function returns the bind with the specified ID. If no argument is passed, the 
bind in the current system task is returned. If no match is found, a NULL value is returnied. 

For example: 

task handshake (bind_var iport. bit direction, bit my.data) 
( 

drive_data(get_bind<) , direction, wy.data) ; 

) 

Synopsyslnc. *"* ' ^ 
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This example declares the task handshake, which is passed three arguments when it is called, includ- 
ing a bind. The task then calls the function drive_data and passes the current bind and two other ar- 
guments when it is called. This ensures that the function drive_data operates on the same port that 
handshake uses. 

get_bindjd0 

The get_bind_idO system function returns the unique ID number for a given bind. Tlie syntax is: 
go t_bind_id ( bind_expressx on ) ; 

bind jexpress ion - The bind^expression can be a bind name, a bind variable, a port variable, or any 
• expression that returns a bind (such as get_bindO). If it is not specified, the current bind ID is 
returned. 

For example: 

task handshake (bind_var iport, bit direction, bit jny_data) 
{ 

x = get_bind_id ( ) ; 

drive_data (get_bind(x) , direction, my_data) ; 

} 

This example gets the current bind ID and passes it to the getJrindO system function. Note that the 
variable x must be declared as a bind_var. 

4.3.4 Using Ports and Binds 

The power of ports and binds comes form the ability to pass them as arguments to tasks and functions 
so that the tasks and functions work on the desired signals. This allows you to define generic tasks and 
functions, independent of the signals they act on. 

The use of ports and binds involves bind_yar and port variables. 

4.3.4.1 bind_var Variables 

Bind.var variables store binds. The syntax to declare a bind_var is: 
bind_vax vari abl e_name = initial_value; 

Specific binds are assigned to bind.vars, and the bind.vars are passed as arguments to tasks and func- 
tions to specify which signals the tasks and functions operate on. For example: 

port rayport (mysignall;mysignal2 ;mysignal3 ) ; 
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bind myport mybind { 

mysignall my inter face. signall; 
mys ignal2 my in t erf ace - signal2 ; 
mysignal3 myinter faces igna 13; 

} 

bind_var mybindvar; 
mybindvar = mybind; 

function integer myfunction (bind_var testport) { 
} 

This code creates the virtual port myport and binds it to the corresponding signals declared in my- 
interf ace. Then it declares the bind_var mybindvar. The code also defines the generic function my- 
function with the arguments testportl. This line, within the main program module calls the function 
with the appropriate port: 

myfunction (mybindvar) ; 

This function call passes the bind.var mybindvar to the function so that the function operates on the de- 
sired signals. 

Bind_vars can be declared as arrays just as any other data type. 

Bind_vars can be assigned different binds, just like an integer variable can be assigned different values. 

Note - You must be careful when assigning new binds to bind_vans and 
passing them as arguments because any bind can be passed to any bind_var. 
For example, if a function acts on 3 signals and you pass a bind with only 2 
signals, a runtime error will occur. There is no type checking to ensure that 
the right bind is being passed. 



4.3.4.2 Port Variables 

Port variables store binds. The syntax to declare a port variable is: 

port_name port^variable e ini tial_ value ; 

portjumt - The portjname is the name of the port data type you are referencing. 

portjvariable - The portjvariable is the name of the port variable you are declaring. 

initial jralue - The initial jvaluc can be any existing port. If it is not set, the portjvariable has a NULL 
value until it is assigned a poii 

When a virtual port is declared, that virtual port becomes a new data type (much like an enumerated 
type). Variables of that type can then be declared and passed as arguments to generic functions and 
tasks much in the same way that bind_vars are. — 
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The key difference between port variables and bind_vars is that only binds of the port data type from 
which the port variable was declared can be passed to the port variable. For example: 

port myportl (mysignall ; my signal2 ;mysignal3 ) ; 
port myport2 (mysignalA;mysignalB;mysignalC) ; 

bind myportl mybindl { 

mysignall myinterface.signall; 
mysignal2 myinterface.signal2 ; 
mysignal3 myinterface.signal3 ; 

} 

bind myport2 mybind2 { 

mysignalA myinterface.signall; 
mysignalB myinterface.signal2 ; 
mysignalC myinterface.signal3 ; 

} 

myportl myportvar = mybindl; 

This code block creates the virtual ports myportl and myport2, and binds the signals to the corre- 
sponding signals declared in myinterf ace. Then it declares the port variable myportvar of type 
myportl with the initial bind mybindl. 

A bind_var could be assigned the bind mybindl. However, assigning the bind mybindl to myportvar re- 
sults in an error because the port types are not the same. 

Port variables can be declared as arrays just as any other data type. 

Note - Port variables provide a stricter method of type checking not afforded 
by bind_vars. For this reason, port variables are generally a preferred means 
of storing binds. 



4.3.4.3 Direct Bind Signals 

Once a port and bind have been declared, bind signals can be referenced directly. The syntax to refer- 
ence a bind signal is: 

bind_or_port_name.$signal_name; 

bindjor _port_name - The bindjor _portjname is the name of the bind in which the signal is referenced 
or the name of the port variable that includes the bind. 

signal jname • The signaljname is the name of the signal as defined in the bind specified (either the 
direct bind specified or the bind with which the port variable is associated). 

For example: 

'port rcv_port' {frame_n # packet} - i 

— . -** 

Synopsysfnc. 



Vera 4.0 User's Manual 



Chapter 4. Basic Vera Programming 75 



bind rcv_port iportO{ 

f raroe_n router . f rame_nO ; 
packet router. diO; 

} 

rcv_port port_val = iportO; 
rcv_port ports [3 3; 
ports ( 1) = iportO; 

router, frame _n0 = 0; 
port_val.$£rame_n = 0; 
ports [ 1] ,$fraxne_n =0; 

This example declares the virtual port icvjport and creates the bind iportO. Then it declares the port 
variables portjval and portsffl, and assigns the bind iportO to portjval and portal]. The last 3 lines arc 
all equivalent methods of referencing the same signal. 



4.3.5 Dynamic Binding 

Vera's dynamic binding capabilities allow you to connect to an HDL signal at runtime and change spec- 
ified interfaces during the simulation based on external conditions. The dynamic binding capabilities in- 
clude void binds, runtime bind declaration, and runtime signal mapping. 

4.3.5.1 Void Binds 

Vera allows you to leave port signals unassigned using the void construct. The void declaration is made 
within the bind: 

port_signal_name void; 

Using the void construct creates a port signal that has no interface signal assigned to it Interface sig- 
nals can be assigned at runtime during the simulation. This is an example of a port and bind declaration 
using void binds: 
port xnyportl 

" •'■'{' : ■■■■■■■■■■■ • ■ ■■ , 

mysignall; 
mysigna!2; 

} ' '' ' 

bind myportl mybindl { 

mysignall myinterface.signall; 
mysignal2 void; 

) 
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4.3.5,2 Runtime Bind Declaration 

Vera allows you to declare new binds at runtime by instantiating port variables. The syntax for runtime 
bind declarations is: 

port_name = new; 
port_name = now bincUname; 

pori_nome - The porijname is the name of the port variable being instantiated. 

bindjname - The bindjname optionally specifies a bind of the same port type as the port variable, 
which specifies how the port signals are initially bound. 

The first construct instantiates the port variable. The port variable is local to the function it is instanti- 
ated in, or global if it is instantiated in the main program. The new port variable is of the same bind 
type as it was declared with all of the port signals unassigned. For example: 

task xny_task() 
{ 

Myport portl, port2; 
portl=new; 

} 

This example instantiates the port variable portl , which will be of bind type Myport with each signal 
being assigned a void value. The resultant bind is: 

bind Myport portl 
{ 

signal 1 void; 
signal2 void; 

signalN void; ... 

signalN - The signals are the port signal names specified in the original bind declaration Myport. 
Alternatively, you can optionally specify another bind of the same port type as the port variable: 

port_name = new bindjname; * 
This construct instantiates the port variable as a bind of the same type as the specified bind. 

Note - The specified bind and port variable must be of the same port type. 



For example: 

bind Myport Mybind 
{ 

signall valuel; 
signa!2 value2; 
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signalN valueN; 

} 

task my_task() 
{ 

Myport portl, port2; 
portl=new Mybind; 

} 

This example instantiates the port variable portl , which will be of bind type Mybind. The resultant 
bind is: 

. bind Myport portl 
{ 

signall valuel; 
signal 2 value2; 

signalN valueN; 

) 

signalN - The signals are the signals specified in the original bind declaration Mybind 
valueN - The signal values are the values as specified in the bind Mybind. 

4.3.5.3 Runtime Signal Mapping 

Vera allows you to map port signals to HDL signals at runtime using the system function 
signal_connectO- The syntax is: 

«ignal_conaect iport_signal. targets ignal [, attributes {. clock} 1); 

port_signol - Hie port_signal is the signal being mapped. It must be a p^rt 
bind. 

target_signal - The target_signal is the new signal to which the port_signal is inapped lt ^ a 
signal reference or a string specifying an HDL node. You can specify subfields within the 
target^signaL == ^ ^«n f .\ 



Synopsystnc. 



78 Chapter 4. Basic Vera Programming 



Vera 4.0 User's Manual 



attributes - The attributes optionally specify how the new connection is made. Multiple attributes can 
be assigned in any order. The attributes with possible values are listed in Table 4-2. 

Table 4-2 signal.connectQ attributes and values 



Attribute 


Possible Values 


dir 


input, output, or izxout 


width 


integer width of signal to connect (default 
is signal width on HDL side) 


itype 


NSAMPZiS or PSAMPLE 


otype 


PHOLD, NHOLD, PDRIVE, MDRXVE, BIRO, NRl, NRX, 
HRZ, PRO , PRl, PRX, or PRZ 


depth 


0 or 1 (default is 0) 


iflkew 


any non -positive integer (default is 0) 


oakew 


any non-negative integer (default is 0) 



This is an example string declaring signal attributes: 

*dir= input width=l itype=PSAMPLE iskew=-3* 
Note that the string is encapsulated in double quotes ( 4 * "). The string is not case sensitive. 

If the target _signal is an HDL node, the attributes must specify at least a minimum complete set 
(direction and signal type). If the targetjsignal is a specific signal, the attributes simply modify the 
existing set of attributes for that signal. 

clock - The clock specifies the clock for any generated interfaces. It can be a reference to an interface 
signal, or it can be a string specifying a signal on the HDL side. Regardless, it must be a 1-bit 
signal (subfields are not allowed). If it is not specified, SystemClock is used. 

When the signal.connectO system function is called, the port signal is connected to the target signal as 
specified. If the port signal was previously connected, that connection is lost when the call is made. The 
connection that is made when the function is called depends on how the call is made. 



Only port_signsl and targetjsignal are specified 

If only the port_signal and targetjsignal are specified, the port_signal is simply remapped to the 
targetjsignal. The targetjsignal must be a signal reference. For example: 

signal_connect(portl.$b, dff.q); 
signal_connect(portl.$b, portl.$a) ; 
signal_connect (portl . $b $a) ; 

The first example connects signal b from portl to signal df £ .q. The second example connects signal 
b from portl to signal a from portl. The third example connects signal b from portl to signal a 
from the port with which the task (with port) is called. 
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target_signal specifies an HDL node 

If the target_signal is a string specifying an HDL node, you MUST include the attributes. When the 
function call is made with the target_signal specifying an HDL node, a new interface is created with the 
given attributes. The clock for the interface is either the clock specified in the function call or Sys- 
temClock if no clock is specified. All the signal interfaces are force driven by Vera at runtime. This 
drive overrides any HDL driving or static interface connections. 

Note - Using this configuration, you cannot connect multi-bit registers or 
portions of registers as output or i nout signals. 

For example: 

signal_connect(portl.$b. -test.top.df f .q[3 :0] - . ~dir=input 
width=4 itype=PSAMPLE iskew=-3*. dff.dk); 

This example creates a new interface with a single connection from the signal portl . $b to the HDL 
node specified by "test_top.dff.q[3:0]." On the DUT side, the signal has a width of 8 bits, but in this ex- 
ample only the 4 least significant bits are connected. The signal has the specified attributes. The inter- 
face clock is df f . elk. 

Note - When using this signal_connectO configuration with Verilog-XL, you 
must use the -x switch at runtime. When using this configuration with VCS, 
you must compile the co de with -P $VERA_HOME/Ub/vcs_pIi_dyn.tab. 

target_signal specifies a signal and attributes or clock is specified 

If the target_signal specifies a signal or interface and either the attributes or clock (or both) is specified, 
a new interface is created. The signal is connected to the specified target and the new interface has the 
given attributes and clock. This configuration for the signal.connectO call is useful for sampling the 
same signal on different clock edges or with a different dock. By changing the attributes or assigning a 
new clock to the signal, you can sample the signal under varying conditions. If you need to sample the 
same signal with a different clock without changing any attributes, you can specify the attributes with 
an empty string(" **). * ' '"• ' ' ' ' "* 

"\ - mm < mm - mmmm ^ 

Note - When using this signal.connectO configuration with Verilog-XL, you 
must use the -x switch at runtime. When using this configuration with VCS, 
you must compile the code with -P $VERA_HOMEAib/vcsjli_dyn.tab. 



4.3.5.4 Dynamic Binding Example 

This is an example of how dynamic binding is used: 
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port port_channel 
{ 

bus_a; 
bus_b; 

} //a port with just 2 bits 

task create_bindings 
( 

• var port_channel arr_binds [ ] , // destination assoc. array of ports 
integer how_many_ports , // how many ports 

string sig_options, // signal options, e.g. "dir=input width=l • 

string sig_clock // the clock to connect to, e.g. •main_mod.clk" 

) 
{ 

integer i ; 
string verpath; 

for (i = 0; i < how_many_ports ; i++) 
{ 

arr_binds[i] = new; // create a binding for this array index 
sprintf (verpath, ■main_mod.bus_a[%Od] i) ; //generate path for bus_a 
signal_connect(arr_binds[i3 . $bus_a, verpath, sig_opt ions , sig_clock) ; 
sprintf (verpath, "main_mod. bus Jb[%0d] i) ; //generate path for bus_b 
signal_connect (arr_binds [ i] . $bus_b, verpath, sig_options , sig_clock) ; 

} 

} 

This example creates an associative array of bindings of type port_channel, and assigns to them 
each bit of main_mod.bus_a and main_mod.bus_b. Each element of the associative array is as- 
signed a different bit of bus_a and bus_b. Note the use of string expressions to specify the HDL path. 



4.4 Signal Operation 

Vera separates its timing and signal operations, which makes test development and maintenance easier 
to handle. The timing is defined in the interface specification, which simplifies signal operation in that 
the skew, and clock are predefined. 

Vera provides four primitive statements that operate on interface signals: 

• Synchronization 

• Drive 

• Sample 

• Expect 

Vera also provides a value change alert (VCA) for use with signals. 

- Synopg^sTlnc. 
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4.4.1 Synchronization 

The synchronization operator (@) is used to perform explicit synchronization. The syntax is: 

e {clock^edge xnterface^signal); 

clock jedge - The clock jedge optionally specifies the clock edge at which the synchronization occurs, as 
defined in the interface declaration. It must be either negedge, which specifies a negative or falling 
clock edge, or posedge, which specifies a positive or rising clock edge. If no clock edge is 
specified, the synchronization occurs on the next change in the specified signal. 

interface signal - The interface_signal specifies the signal to which the synchronization is linked. It 
can be any defined signal or CLOCK. The interface signal can be any subfield of a signal as well. 
If a signal is not specified, the interface is clocked by SystemClock. 



Note - Only 1 bit signals can be synchronized on the posedge or negedge. 



If the interface signal is a subfield of a signal, the synchronization occurs on the first change of the sig- 
nal subfield. If the subfield is a 1-bit subfield, you can synchronize on clock edges. If you specify vari- 
ables in the subfield, Vera evaluates the variables at runtime. 

You can use the OR keyword to specify multiple interface signals. If you specify more than one signal, 
the synchronization occurs on the next change of any of the listed signals. 

These are some example synchronization statements: 

e ( f oo_bus . ack_l ) ; 

G( CLOCK ); 

8( posedge foo_bus .clock ); 

G( negedge intfc.signla:b] ) ; 

The first example synchronizes to the clock edge corresponding to the next change of the ack_l sig- 
nal, as declared in the f oo_bus interface specification. The second example synchronizes to the Sys- 
temClock. The third example synchronizes to the positive edge of the interface clock. The last 
example synchronizes to the falling edge of the specified subfield. 

Note that at initialization, HDLs can create edges at time = 0 (for example, going from X to the ini- 
tialized value). This means that synchronization conditions can be set before initialization of the signal. 

4.4.2 Drive 

Drives set the value of output interface signals. The syntax to drive a signal is: 
delay signal_name range drive_operator expression; 

delay - The delay specifies the number of cycles that pass before the signal is driven. It is in the form 
@n where n is the number of cycles. 

signaljname - The signal jname is the name of the signal being driven. 
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range - The range specifies which bits of the signal are driven. If no range is specified, the entire 
signal is driven. 

drive ^operator - The drive_operator must be either =, which specifies a blocking drive, or <=, which 
specifies a non-blocking drive. 

expression - The expression can be any valid Vera expression. 

These are some drive examples: 

foo_bus.data[3:0] = 4'h5; // blocking drive 
61 foo_bus.data <= 8'hz; // non-blocking drive 

4.4.2.1 Blocking and Non-Blocking Drives 

There are two types of drives specified by the drive operator blocking and non-blocking. Blocking 
drives suspend Vera execution until the number of HDL cycles specified in the delay passes. Note that 
the specific time within the cycle that the drive unblocks is determined by the clock edge on which the 
drive takes place (NHOLD or PHOLD). Once the delay passes, Vera execution resumes. Non-blocking 
drives schedule the drive at a future cycle and Vera execution continues. When the specified cycle oc- 
curs, the drive is executed. 



Note - For performance reasons, input and output skews are implemented 
with delay buffers to minimize the amount of interaction of Vera with the 
simulation. Unless you use the delayO system task or asynchronous signal 
operations, Vera only interacts with the simulation at clock edges. 

These are some blocking and non-blocking examples: 

63 foo_bus.data = 1; 
a = b; 
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@3 foo_bus.data <= 1; 
a = b; 



t 

foojbus.data = 1 
a=b 



t i 

a =b . f oo_bus . data = 1 

The first block is a blocking drive. Three cycles must pass before the second line is executed. The sec- 
ond block is a non-blocking drive. The drive is delayed three cycles. The second line is executed, and 
the simulation advanced three cycles before the first drive is executed. 



4.4.2.2 Strong and Soft Drives 

There are two strengths of drives: strong (default) and soft. The syntax to declare a soft drive is: 
delay signal_name range driye^operator expression soft; 

A given signal should only be driven by a single strong drive at any given time. Multiple strong drives 
at the same time result in conflicting drives. Conflicting strong drives drive the signal to X and result in 
a simulation error. However, conflicting soft drives can drive a signal to X without causing a simulation 
error. Finally, if a signal is driven by a conflicting strong and soft drive, the strong drive dominates and 
the signal is driven by the strong drive. 

4.4.2.3 Void Drives 

Drives block until the appropriate driving clock edge occurs. If you want to wait for this clock edge 
without actually driving the signal, use the void construct The syntax is: 

delay signal_name = void; 

For example: 

61 iportO. packet = void; 
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4.4.3 Sample 

Samples assign the value of a signal to a variable. The syntax is: 

variable - signal^name; 

The signal value can be an interface signal or a port signal, but it must be an input or inout signal. It is 
sampled at the next sampling point (specified in the interface file) and the value is assigned to the vari- 
able. It cannot be delayed like drives can. Remember that you can sample previous cycles using the sig- 
nal depth construct (see Section 4.3.1.3, "Signal Depth"). Also remember that you can sample subfields 
within the signal by specifying a specific subfield in the signal width. 



Note - When you sample a signal in an expression, it is done immediately. 



AAA Expect 

The expect event asserts that a given signal has a given value at a given time. There are several forms 
of the expect primitive: 

• Simple expect - @ 

• Full expect - @@ 

• Restricted - @@@ 

The general syntax for an expect statement is: 

expect_operator delay window expect_list; 

expect _operotor - The expect joperator must be either @, which specifies a simple expect, @@, which 
specifies a full expect, or @@@, which specifies a restricted expect. Each form is discussed in 
detail in subsequent sections. 

delay - The delay specifies the number of cycles that pass before the signal is driven. It is in the form 
@n where n is the number of cycles. A delay must be specified. For immediate checking, use a 
delay value of 0 cycles. 

window - The window specifies how long the check is made. It must be in the form ji where n is the 
number of cycles for which the check is made. The comma (,) immediately follows the delay. Any 
expect with a defined window is called a floating expect 

expect Jist - The expect Jist is any number of expressions (separated by commas) using the equal to 
(=) and not equal to (!=) operators. The bit value *X f is treated as a "don't care" in expressions. 
The general form is signal jname operator expression. Signal names can be interface or port 
signals, and they can include subfields. If multiple expressions are declared, they are all sampled on 
the clock edge of the first signal in the list 



Note - The expect primitive is a blocking primitive. It blocks until the expect 
is satisfied or a simulation error is generated. There is not a non-blocking 
form of the expect primitive. 
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4.4.4.1 Simple Expect 

The simple expect checks that a given signal has a specific value at a given time. The syntax is: 

G delay window expect^list; 

If the signal value does not match the expression when the check is made, a simulation error is gener- 
ated. If a subfield within the signal is specified, all other bits in the signal are ignored and only those 
specified are checked against the expression. 

Multiple expressions can be defined in the expect Jist. If multiple expressions are defined, the expect is 
satisfied if ALL of the conditions are satisfied at the time of the sample. 

Expressions can also be separated by the or keyword. In that case, the expect is satisfied if any of the 
conditions is satisfied at the time of the check. 

Note - You cannot mix comma separated expression lists with or lists. 

If a window is specified, the expect is a floating expect The check is made for the duration of the win- 
dow. If the signal value matches the expression at any time within the window, the expect is satisfied. 
If the signal value does not match the expression within the window, a simulation error is generated. If 
multiple expressions are defined, the expect is satisfied when all the conditions are satisfied simulta- 
neously. If the or keyword is used, the expect is satisfied as soon as any of the conditions is satisfied. 



•V V 



These are some examples of the expect statement: 

ei bus.data[7:4] == 4'b0101; 
80,10 bus. data == 4'bxOxl; 

61 bus. data == 4'b0010, bus.addr != 4'b0001; 
32,20 bus. data == 4'b0010, bus.addr != 4'b0001; 
62,20 bus. data == 4'b0010 or bus.addr == 4'b0001; 

The first example expects the signal data to be equal to 0101 after 1 cycle. ' * ' ' 

The second example expects the signal data to be equal to 1011, 1001, 0011, or 0001 within 10 cy- 
cles. 

The third example expects the signal data to be 0010 and the signal addr not to be 0001 after 1 cycle. 

The fourth example expects the signal data to be 0010 and the signal addr not to be 0001 within 2 to 
20 cycles. 

The fifth example expects the signal data to be 0010 or the signal addr to be 0001 within 2 to 20 cy- 
cles. 



4.4.4.2 Full Expect 

Full expects check that a signal has a given value over the entire length of a given interyaL The syntax 
is: 
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TO delay window expect_list; 

Full expects behave in the same manner as simple expects with one exception. The signal value must 
match the expression over the entire course of the defined window. If the signal does not match during 
any part of the interval, the expect is not satisfied and a simulation error is generated. 

This is an example of a full expect statement: 

605,100 bus.data[7:4] != b'0101, bus.addr == 8'h88; 

This example is satisfied if the signal data is not equal to 0101 and the signal addr is equal to 88 
over the entire interval, 5 to 100 cycles. 

4.4.4.3 Restricted Expect 

Restricted expects check that a signal's value changes to a given value on the first signal change. The 
syntax is: 

delay window expect__list; 

Restricted expects check that the signal matches the expression on the first signal change within the 
window. If the signal value does not match the expression after the first signal change, a simulation er- 
ror is generated. If the signal value matches the expression at the start of the window, the expect is sat- 
isfied immediately. If multiple expressions are defined using an AND construct, all of the conditions 
must be satisfied at the time of the first change to any of the signals, or else a simulation error is gen- 
erated. 

These are some examples of restricted expects: 
©000,100 bus.addr == 8'h01; 

6000,100 bus. data == 8'h88, bus.addr == 8'h01; 
The first example is satisfied if the first change of signal addr is to 01. 

The second example is satisfied if the first change of signal data is 88 and the signal addr changes to 
01 simultaneously (or if it is already 01). The second example is also satisfied if the first change of sig- 
nal addr is 01 and the signal data changes to 88 simultaneously (or if it is already 88). 

4.4.4.4 Strong and Soft Expects 

There are two strengths of expects: strong (default) and soft. The syntax to declare a soft expect is: 
expect^operator delay window expect^list soft; 

Soft expects do not generate simulation errors when they are not satisfied. Instead, they set an error flag 
and the simulation continues. You can check if an error flag has been set using the flagO system func- 
tion (see Section 73. l t "Error Handling*'). 

"* * ^ 

The soft keyword can be used with any of the expect primitives. 



Vera 4.0 User's Manual Chapter 4. Basic Vera Programming 87 



4.4.4.5 Void Expects 

Expects are blocking in that if the Vera thread that executes them is not at the appropriate clock edge, it 
blocks until the appropriate clock edge occurs. If you want to wait until this clock edge without expect- 
ing the signal, use the void construct. The syntax is: 

© delay signal_name == void; 

For example: 

ei iportO. packet == void; 

4.4.5 Value Change Alert (VCA) 

The value change alert (VCA) checks that no unexpected event occurs on a signal during the simula- 
tion. VCAs are declared within the interface specification. The syntax to declare a VCA is: 

signal^direction signal_width signal^name signal_type skew vca Q_value; 

qjvolue - The qjyalue is the quiescent state of the signal. The valid q_values are listed in Table 4-3. 



Table 4-3 


VCA q_value 


q_value 


Definition 


rl 


Signal returns to 1 (pullup) 


iO 


Signal returns to 0 (pulldown) 


TZ 


Signal returns to z (tri) 


rx 


Signal returns to x (forced or driven) 


nr 


Signal holds last value (all transitions are flagged) 


srl 


Signal returns to 1 (pullup) 


srO 


Signal returns to 0 (pulldown) 


srz 


Signal returns to z (tri) 


SIX 


Signal returns to x (forced or driven) >■ 


snr 


Signal holds last value (all transitions are flagged) . 


grl 


Signal returns to 1 (pullup) 


grO 


Signal returns to 0 (pulldown) . 


grc 


Signal returns to z (tri) 


grx 


Signal returns to x (forced or driven) 


gnr 


Signal holds last value (all transitions are flagged) 



The qjvalue for a vector applies to all bits in the vector. Thus an 8-bit bus defined 

as rl has the qjvalue 8 f hff f rO would have a q_value 8'hOO, rz 8'hzz, rx 8'hxx, and nr would have 

a q value equal to whatever the previous value was. 
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The q_yalues rl, rf), rz, rx, and nr are asynchronous delects and detect any asynchronous changes 
except zero-delay glitches. The q_yalues srl, siO, srz, srx, and snr are synchronous detects and only 
detect errors at synchronous clock edges. The q_values grl, giO, grz, grx, and gnr are glitch detects 
and detect all asynchronous changes including zero delay glitches. 

You only need to define qjvalues for those signals that have the VCA enabled for them. 



Note - The VCA cannot be used with output signals. 



This is an example of a signal declaration with the VCA specification: 
input b PSAMPLE depth 1 vca rz; 

Declaring a qjvalue in the interface specification does not enable the VCA for a signal. By default, all 
signals are VCA-disabled. To enable and disable the VCA for a signal or interface, use the system task 
vca(). 

vcaO 

The vcaO system task enables and disables VCAs. The syntax is: 
vca ( swi tch [ , signal_name] ) ; 

switch - The switch must be either ON, which enables the VCA for the specified signal, or OFF, which 
disables the VCA for the specified signal. The default value is ON. 

signal _nome - The signaljname can either be the name of an interface, which enables or disables all 
VCAs within the interface, or it can be the name of an individual signal in the form 
interface jname signaljname. 

This is an example of the vcaO system task: 

vca (ON, myinterf ace) ; 
vca(OFF, myinterface.sign.all) ; 

When a VCA is enabled for a particular signal, Vera checks that all changes to signals are to the quies- 
cent state (q_value) unless there is a matching expect on the next sampling edge or the signal is explic- 
itly driven to the new state. .., 

After a change is made, the VCA does not drive the signal back to the quiescent state. To return the sig- 
nal to its quiescent state, you must explicitly drive it 

Note that for pipelined signals, VCA reports are delayed. This is because Vera must first find out if 
there are any expects in the pipelined version of the signal that affect whether a value change is expect- 
ed or noL So, Vera must wait until all of the cycles specified have been executed, and then it produces 
applicable VCAs. 

Note - VCAs are implemented such that they do not slow down the 
simulation in any significant way. 
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4.4.6 Implicit Synchronization 

The drive, sample, and expect primitives perform implicit synchronization to the interface CLOCK. 
That means that the clock is advanced only when it is necessary to perform the next signal operation. 
Take the following interface definition as an example: 

interface foobus { 

output reset_l NHOLD; 
input strobe_l PSAMPLE; 
output ack_l NHOLD; 
inout data PSAMPLE NHOLD; 
input clock CLOCK; 

} 

In this interface, output signals are driven at the negative edge of the interface clock, and input signals 
are sampled at the positive edge of the interface clock. Thus, the following code advances the simula- 
tion cycle a half cycle per statement even though a delay is not specified. 

reset_l = l'bl; 
strobe_l == l'bl; 
ack_l = 1'bO; 
strobe_l == 1'bO; 

The first signal is driven on the negative clock edge. The second signal is sampled on the positive clock 
edge. The third signal is driven on the negative clock edge. The fourth signal is sampled on the positive 
clock edge. 

The description gets more complicated when delay values are used to generate proper timing with re- 
spect to different edges. To avoid this, use the same edge for inputs and outputs, with appropriate output 
skews. For example: 

interface foobus { : ' 

output reset_l PHOLD #2; 
input strobe_l PSAMPLE; 

output ack_l PHOLD #2; ' * " 

inout data PSAMPLE PHOLD #2; . 
input clock CLOCK; 

} 



4.5 Asynchronous Operations 

By default, drives, samples, and expects are relative to a clock edge (specified in the interface specifi- 
cation). However, the HDL side of the simulation may be using very detailed timing constructs. Vera 
provides the async and delay constructs to allow detailed timing down to the HDL timestep. 
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4.5.1 



async 



The async optional modifier specifies that the operation happen immediately, without waiting for the 
edge specified in the interface. It can be used with synchronization operators, drives, samples, and ex- 
pects. The syntax is: 

Sync; @ (signal_name async) ; 

Drive: signal_name range drive_operator expression async; 

Sample: variable = signal^name async; 

Expect: 0 expect^list async; 

The synchronization construct allows you to act exactly on the specified edge rather than waiting for 
the corresponding sampling edge. 

The drive, sample, and expect constructs force the operation immediately instead of waiting for the 
specified edge. 



If a signal has a VCA enabled for it, driving it with the async option results in a VCA error. Disable 
any active VCAs when driving signals asynchronously. 

These are examples of async statements: 

0 (posedge ma in_bus . request async) 
memsys .data [3 :0] = 4'bl010 async; 
data [2:0] = main_bus . data f 2 : 0 ] async; 
fcmain_bus.data[7 :4) == 4'b0101 async; 



Vera provides the delayO system task to block Vera while a specified amount of time elapses on the 
HDL side of the simulation. The syntax for the delayO system task is: 

delay ( time) ; 

time - The time specifies the length of the delay. It is in the same timing units being used by the HDL. 
This is an example of the delayO system task: 

6 (posedge CLOCK) ; 
delay(5); 
function! () ; 



Note - Drive skews specified for the signal in the interface specification also 
apply to async drives. If you need to drive the signal precisely when the drive 
is issued, do not specify any skew for that signal in the interface 
specification. 



4.5.2 



Sub-Cycle Delays 
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This example synchronizes to the positive edge of CLOCK. Then it advances the simulation time 5 time 
ticks. Functionl executes 5ns after the clock edge. 

Note - This does not work with Vera-CS because there is no HDL design 
generating a clock. 



o 

. ITT 



4.6 Subroutines 

Vera supports two means of encapsulating often-executed program fragments: functions and tasks. All 
functions and tasks are re-entrant and can be called recursively. 

Vera subroutines cannot be nested. This means that all subroutine declarations must be done at the top 
level. To ease the name space problem. Vera supports local subroutines and separate compilation. You 
can also declare external subroutines. These separately compiled Vera object files are linked at simula- 
tion time (see Section 18.6, "Modular Compilation"). 

4.6.1 Functions 

Functions are provided for implementing mathematical functions containing some number of arguments 
and one return value. Functions can be used in expressions in order to perform frequently used calcula- 
tions, or to encapsulate the calculation. The syntax to declare a function is: 

function data_type £unction_name (arguments) {statements; } 

dotajype - The data.type can be any of the valid Vera data types. The value returned will be of the 

same data type that the function is declared with. 
function_name - The function_name is the name by which the function is called throughout the 

program. 

arguments - The arguments are the variables, including the data types, that are passed to the function 
when the function is called. All data types can be passed, including ports. Array arguments can be 
regular or associative, as well as var. Array arguments are strongly typed. Array type, width, and 
size must match exactly between the declaration and the call. Multiple arguments are separated by 
commas. . - 

statements - The statements can be any Vera statement, including function calls, timing modifiers, and 

variable assignments. . _ „ 

Functions are designed to return a single value. They can return values of any data type as well as data 
structures. To set the return value, assign the name of the function a value somewhere within the func- 
tion declaration. 

This is an example function declaration: 
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function bit [3:0] even_byte_parity (bit [31:0] data) 
{ 

bit [3:0] tmp; 

tmp[3] = A data[31:24] ; 
tmp[2] = ~data[23:16] ; 
tmptl] = *data[15: 8] ; 
tmp[0] = ~data[ 7: 0] ; 
even_byte_parity = tmp; 

} 

This example declares the function even_byte_parity with the argument data. Note the final line 
of the function, which contains the line that sets the return value. 

Functions can be called in expressions from within the main program or from within other functions. 
The syntax to call a function is: 

variable = function (arguments) ; 

For example: 

parity = even_byte_parity (Data) ; 

By default, function names are global. Functions declared as local can only be used in the file where 
they are defined. To invoke a function defined in another file, you must use the extern declaration (see 
Section 4.6.7, "External Definitions"). The syntax to declare a local function is: 

local function data_t>^?e function_name {arguments) {statements; } 

i, 

For example: 

local function bit [3:0] g_decode ( integer i ); 



4.6.1 .1 Discarding Function Return Values 

Vera enforces the use of function return values. Calling a function as if it has no return value results in 
compilation errors. To explicitly discard a function's return value, use the void construct The syntax is: 

void = function {arguments) ; 

4.6.2 Tasks 

Tasks are identical to functions except they do not return a value. The syntax to declare a task is: 
task task__name {arguments) {statements; } 

toskjnome - The toskjnome is the name by which the task is called throughout the 
program. 
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arguments - The arguments arc the variables, including the data types, that are passed to the function 
when the function is called. All data types can be passed, including ports. Array arguments can be 
regular or associative, as well as var. Array arguments are strongly typed. Array type, width, and 
size must match exactly between the declaration and the call. Multiple arguments are separated by 
commas. 

statements - The statements can be any Vera statement, including function calls, timing modifiers, and 
variable assignments. 

This is an example task declaration: 

task handshake_portO (bit direction, bit [7:0] data) 
{ 

00,1000 portO.req == l'bl; 

portO.ack = l'bl; 

01 portO.ack <= 1'bO; 

if (direction) portO.data = data; 

else portO.data == data; 

} 

Tasks can be invoked as statements. The syntax to invoke a task is: 
task^_name ( argumen ts ) ; 

For example: 

print_data(new_data) ; 

By default, task names are global. Tasks declared as local can only be used in the file where they are 
defined. To invoke a task defined in another file, you must use the extern declaration (see 
Section 4.6;7, "External Definitions") - The syntax to declare a local task is: 

local task task^name (arguments) {statements; } 

For example: 

local task print_data (bit (7:0] data) 

prihtf ( 'Local data = %h*, data); 

} 

4,6.3 Return 

Normally, functions and tasks return control to the caller after the last statement of the block is execut- 
ed. Vera provides the return statement to manually pass control back to the caller. The syntax is: 

return; 
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When the return statement is executed, the subprocess is terminated as if it had been exited normally. 
If the return statement is executed in a function before a value has been assigned, an undefined value 
is returned. 

If a return statement is executed at the top code level, the simulation is terminated. 



4.6.4 Breakpoint 

Vera provides the breakpoint statement to stop the simulation and return control to the HDL. The syn- 
tax is: 

breakpoint; 

When a breakpoint statement is executed, Vera terminates the task or function immediately and returns 
control to the HDL. You must restart the simulation from the HDL command line. Simulation time con- 
tinues while the process is terminated. So be careful when using breakpoints because the simulation 
time is not handled precisely on restart. 

If a breakpoint statement is executed at the top code level, the simulation is terminated. 
When a breakpoint statement is executed, the Vera debugger is launched. 

4.6.5 Static Variables 

By default, variables are local to the function or task that uses them. They are allocated when the func- 
tion or task is called. This construct allows tasks and functions to be re-entrant and recursive. 

If you want a variable to be shared across all invocations of a function or task, use the static declara- 
tion. The syntax to declare a static variable is: 

■tat ic da ta_ type vari abl e__iiame ; 
Any data type can be declared as a static variable. 

Note - In the case of concurrent accesses, there may be races if multiple 
threads assign to the same static variable. 



4.6.6 Subroutine Arguments 

Vera provides two means of accessing arguments in functions and tasks: "call by value*' and "call by 
reference." 
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4.6.6.1 Call by Value 

"Call by value" is the default method that arguments arc accessed in functions and tasks. Each subrou- 
tine retains a local copy of the argument If the arguments are changed within the subroutine, the chang- 
es do not affect the caller. 



4.6.6.2 Call by Reference 

In a "call by reference" functions and tasks access the specified variables passed as arguments directly. 
The syntax to pass a subroutine argument by reference is: 

subroutine (var datatype variable) ; 

In a "call by reference" subroutines operate directly on the var arguments. The caller sees any changes 
to variables made within the subroutine. Variables of any type can be passed by reference. 

This is an example of a "call by reference": 

task IO_read_indirect ( bit [63:0] addr, var bit [31:0] io_data ) 
{ 

// ... (modifies both addr and io_data) 

// ... (only the change in io_data will be seen by caller) 

) 

// caller 

IO_read_indirect (my_addr, my_data ) ; 

In this example, the variable iojdata is passed by reference. The task modifies all of the arguments 
passed, but only the change made to iojdata is seen outside the task. 



4.6.6.3 Default Arguments 

To handle common cases or allow for unused arguments, Vera allows you to define default values for 
each scalar argument The syntax to declare a default argument in a subroutine is: . 

subroutine(arg=der"ault_ value) (statements) 

defauU_value - The default _xa\ue can be any expression visible at the current code level. It can include 
any combination of constants, global variables, and functions. 

When the subroutine is called, you can omit an argument that has a default defined for it Use an aster- 
isk (*) as a placeholder in the subroutine call. If an asterisk is used for a variable that does not have a 
default value, a compilation error occurs. 

This is an example of a subroutine with default arguments: 

task foo( integer i = 0, integer k, bit[5:0) data = 6'bO) { 
//•• 
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foodOO, 5, *); 
foo(*, 5, 6'b000111); 

This example declares a task f oo with default arguments. The first call to f oo is equivalent to 
foo(100, 5, 6'bO). The second call to foo is equivalent to £oo(0,5,6'b0001ll). 

4.6.6.4 Optional Arguments 

To allow subroutines to evolve over time without having to change all of the existing calls, Vera sup- 
ports optional arguments. Optional arguments are encapsulated by parentheses, and they must have de- 
fault values. The syntax is: 

subroutine^ {optional^argl) , ( ioptional_arg2) ) , ( ( {optional_arg3) ) ) ) 
{statements} 

Any number of additional optional arguments can be created. The number of nested parentheses deter- 
mines the depth level of the optional argument For example: 

((x=l)), <(y=U) // Both arguments are level 2 
(<x=l, y=l) ) // Both arguments are level 2 
<<x=l), <<y=l))) // x is level 2, y is level 3 

When a subroutine with optional arguments is called, the parameters fill up the lowest level arguments 
first. When the lowest level is satisfied, higher levels are then filled in ascending order. Note that the 
order of the arguments does not depend on the nesting level. For example: 

task my_task(a, ( (b=l) ) , (c=l)); 

This example declares a task with the required argument a, the level one argument c, and the level two 
argument b. These are examples of task calls using this declaration: 

my_task(); // Illegal because the argument a has no default 
my_task(l); // Calls task with a=l 
my_task(l,2) ; // Calls task with a=l and c=2 

Note that the arguments are filled according to their nesting level. However, if enough arguments are 
passed to fill all of the optional arguments, the arguments are assigned values in order. For example: 

my_task (1,2,3); // Calls task with a=l, b=2, and c=3 

4.6.7 External Definitions 

External definitions allow you to use multiple source files. This lets you compile large functions sepa- 
rately, which facilitates debugging. 
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4.6.7.1 Declaring External Subroutines 

You can create subroutines in multiple source files. If you use multiple source files, you must declare 
the subroutines as external at the top level. The syntax to declare a subroutine as external is: 

extern subroutine (arguments) ; 

Alternatively, you can generate a header file when you compile the source code by using the -h switch 
(see Section 18.4, "Compile Options"). The generated header file contains all of the extern statements 
for that module. If you include this file, you do not need to manually declare the subroutines as extern. 



Note - When using external subroutines, the argument types that are passed 
must match exactly. So take extra care when passing arguments to external 
subroutines. 



j3 4.6.7.2 External Default Arguments 

01 The default values can be set locally, and independently, for each compilation unit using extern decla- 

Q rations with default values. This allows writing a general library, which can then be customized for a 

S particular user or testbench by using include files with different defaults. 

jj J £ 

b j For example, the task f oo may be defined in a separate library, which is compiled independently. The 

s Vera file in which the task foo will be used must declare f oo as being external, and in this extern dec- 

laration, you can set default values: 

// file A (library) 

pj task foo (integer i, k, bit 15:0] data) { 
jp // foo definition 

f~fc } 

// file B (testbench) 

extern task foo ( integer i = 10/ integer k, bit[5:0] data=6 'bllllll ); 

task xyz () { 

foo (*. 5, *); 
7/ ... 

) 
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Example 1 : Vera Basics 

This is an example of an arbiter. The example includes these features: 

• File inclusion and text macros 

• Interface specification 

• Ports and binds 

• Signal operation 

• Subroutines 

This example includes these files: 

• arb.if.vr 

• $ignaljirive.vr 

• RUN (a run script) 

arb.if.vrh 

#define OUTPUT_SKEW #1 
fdefine INPUT_EDGE PSAMPLE 

interface arb 
{ 

output [1:0] bus_req PHOLD OUTPUT_SKEW; 

input 11:0] bus_gnt INPUT__EDGE vca rO; // vca monitor 

output [31:0] mem_addr PHOLD OUTPUT_SKEW; 

inout [15:0] mem_data INPUT_EDGE PRZ OUTPUT_SKEW vca rz; // vca monitor 

output oe PHOLD OUTPUT_SKEW; 

output ce PHOLD OUTPUT_SKEW; 

input ack INPUT_EDGE vca rO; // vca monitor 

input elk CLOCK; 

> 

port generic_port 
{ 

br; 
bg; 
addr ; 
data; 
oe; 
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ce; 



ack; 



} 



bind generic_port port_a 
{ 

br arb . bus_req [ 0 ] ; 
bg arb,bus_gnt [0] ; 
• addr arb.mem_addr; 
data arb.mem_data; 
oe arb.oe; 
ce arb.ce; 
ack arb. ack; 



bind generic_port port_b 
{ 

br arb . bus_req [ 1 ] ; 
bg arb . bus_gnt ( 1 ] ; 
addr arb . mem_addr ; 
data arb . mem_data ; 
oe arb.oe; 
ce arb.ce; 
ack arb. ack; 



f include <vera_def ines.vrh> 
# include •arb.if.vrh- 

program signal_test 
{ 

bit 115:0] write_data_a[4] , write_data_bt4] , rea<3Ldata_a[4] , 
read_data_b[4] ; 

// reset the request 

80 port_a.$br <= 1'bO ; 
60 port_b.$br = 1'bO ; 

// turn vca on for unexpected signal changes 
vca ( ON, arb ) ; 

// initiate burst write with both port_b and port_a at the same time 



} 
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fork 
{ 

// port b 

integer i ; 

for ( i = 0; i < 4; i++ ) 

wri t e_da ta_b ( i ] = random ( ) ; 
do_write with port_b ( 32 *h0000_0008, write_data_b ); 

} 
{ 

// port a 

integer i; 

for ( i = 0; i < 4; i++ ) 
write_data_a[i] = random (); 

do_write with port_a ( 32 'h0000_0004 , write_data_a ); 

} 

join all 

// initiates burst read with both portjb and port_a at the same time 
// and verify the results 

fork 

{ //concurrent block 
// portjb 

integer i ; 

do_read with port_b ( 32 'h0000_0008, read_data_b ); 

for ( i = 0; i < 4; i++ ) 

{ 

if ( read_data_b[i] !== write_data_b[i] ) 

error ( "port_b transactions gives inconsistent data!\n'); 
else 

printf Cport_b data %0d OK!\n" # i ); 

) 

} // end concurrent block 
{ //concurrent block 
// port_a 

integer i; 

do_read with port_a ( 32 'h0000_0008, read_data.a ); 

for ( i = 0; i < 4; i++ ) 

{ 

if ( readl_data_a[i) !== write_data_a ti] ) 

error ( "port_a transactions gives inconsistent data!\n"); 
else 

printf Cport_a data %0d OK!\n*. i ); 

) 

} // end concurrent block 
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join all 

printf ( * \n All Finished \n" ) ; 

}//end program 

// do_read : request bus Ctrl from arbiter and do burst read at the 
// addr 

task do_read with generic_port ( bit [31:0] addr, var bit [15:0} data [4) ) 
{ 

61 $br = l'bl; // start requesting for bus 

61, 12 $bg == l'bl; // bus should be grant within 12 cycles 
60 $br = 1'bO; // stop the request immediately 

62 $bg == 1'bO; // grant signal should be de-asserted 

60 $addr <= addr; // drive the addr, oe, ce bits 
$oe = l'bl; 

$ce = l'bl; 

62, 10 $ack == l'bl; // ack should have come within 8 cycle 
fork 

{ // concurrent block 

660, 3 $ack == l'bl; // ack should stay for 4 cycles 

60 $oe <= 1'bO; // at the end, deassert oe and ce 

60 $ce = 1'bO; 
} // end concurrent block 
{ // concurrent block 

integer i; 

for (i = 0; i < 4; i++) // latch the data for 4 consecutive cycles 
{ 

6(posedge CLOCK); 

data[i] = $data; 
}//end for 
} // end concurrent block 
join all 

61 $oe = void; // void drive to kill one more cycle 
}//end do_read 

// do_write : request bus Ctrl from arbiter and do burst write at 
// the addr 

task do_write with generic_port ( bit [31:0] addr, bit [15:0] data [4] ) 
{ 

61 $br = l'bl; // start requesting for bus 

61, 12 $bg == l'bl; // bus should be grant within 12 cycles 
60 $br = 1'bO; // stop the request immediately 

62 $bg == 1'bO; // grant signal should be de-asserted 
60 $addr <= addr; // drive the addr, oe, ce bits 

$oe = 1'bO; 



Si 

■3 

~? - 
3^1 



Vera 4.0 User's Manual Example 1: Vera Basics 103 



$ce = l'bl; 

62, 10 $ack == l'bl; // ack should have come within 8 cycles 

fork 

{ 

630, 3 $ack == l'bl; // ack should stay for 4 cycles 
60 $ce = 1'bO; 

) 
{ 

integer i; 

for (i = 0; i < 4; // drive the data for 4 consecutive cycles 

{ 

$data = data[i] async; 
@ (posedge CLOCK) ; 
} //end for 

> 

join all 

91 $oe = void; // void drive to kill one more cycle 
}//end do_write 



RUN 



#!/bin/csh -f 

rm -f core *.vro Wshell >& /dev/null 
vera -cmp -g s ignal_dr ive . vr 



— 
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5. Sequential Control 

This chapter discusses the Vera constructs used for sequential flow control. It includes these sections: 

• If-else Statements 

• Case Statements 

• Randcase Statements 

• Repeat Loops 

• For Loops 

• While Loops 

• Break and Continue 

5.1 If-else Statements 

Vera supports if-else statements as the general form of selection statements. Hie syntax to declare an if- 
else statement is: 

if {condition) i /.statement el«e el se_sta Cement; * * 

6 

condition - The condition can be any valid Vera expression. 

statement • Either statement can be any valid Vera statement or block of statements. If a code block is 

used, the entire block is executed. 
If the condition evaluates to true, the if_statement is executed. If it is evaluated to false, the 
else_statement is executed. 

The else statement can be omitted. If the else statement is omitted, the conditional is equated and the 

if, statement executes only if it evaluates to true. Otherwise, the program continues execution with the 

first line after the if statement. 

Vera supports nested if-dse statements. 

This is an example of an if-else statement: 

if (operator==0) y=a+b; 
else if (operator==l) y=a-b; 
else if (opera tor==2) y=a*b; 
else y='bx; 

This example uses several if-else statements. Note that the final else statement is associated with the if 
statement immediately preceding it - 

Vera also supports ? operator to replace if-else statements. The syntax is: ^ 
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condition ? if ^statement : else_statement; 

This construct behaves exactly as the if-else construct. The condition is evaluated. If it evaluates to true, 
the if__statement is executed. If it does not evaluate to true, the else_statement is executed. 

5.2 Case Statements 

Vera provides the case statement for multi-way branching. The syntax to declare a case statement is: 

case (primary_expression) { 

case ^expression : statement; 
case2_expression t statement; 

caseAL express ion x statement; 
default : statement; 

} 

expression - The expressions can be any valid Vera expression. 

statement - The statement can be any valid Vera statement or block of statements. If a code block is 
used, the entire block is executed. 

The primary ^expression is evaluated. The value of the primary_expression is successively checked 
against each casejexpression. When an exact match is found, the statement corresponding to the match- 
ing case is executed, and control is then passed to the first line of code after the case block. If other 
matches exist, they are not executed. If no match is found, the default statement is executed. 

All case expressions must be the same bit length. 4 X* and *Z' values are actual signal values and are not 
ignored. 

This is an example case block: 

case ( bus [3:01 ) < 

4'bOOZZ: packet = NULL; " 
4'b0001: packet = READ; 
4'b0010: packet = WRITE; 
4,b00XX: packet = UNKNOWN; 
default: 
{ 

printft *Error: illegal packet %h detected\n*, bus [3:0] ); 
packet_error ( ) ; 

} 

} 

If you want to use *X' or *Z* as a "don't care", use the casex or casez statements. *X' values are ig- 
nored when using casex, and 'Z' values are ignored when using casez. 
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5.3 Randcase Statements 

The randcase statement creates a block of statements, one of which is executed randomly. The syntax 
to declare a randcase block is: 

randcase { 

weightl : statementl; 
weight 2 i statement2; 



weightN : statementN; 

} : : Y 

weight - The branch weight can be any valid Vera expression, including a constant The expression is 
evaluated every time a randcase is executed. 

statement - The statement can be any valid Vera statement or block of statements. If a code block is 
used, the entire block is executed. 

When the randcase statement is executed, a statement is randomly selected from the block, different 
weights can be used to change the probability that any given statement is selected. The probability that 
any single statement is selected is determined by weightftotal_weight. 

Randcase statements can be nested. 

This is an example of a randcase block: 

randcase { 
10: i=l; 
20: i=2; 
50: i=3; 

) 

This example defines a randcase block with the specified weights. There is a .125 probability that the 
first statement is executed, a 25 probability that the second statement is executed, and a .625 probabil- 
ity that the third statement is executed. 

5.4 Repeat Loops 

The repeat loop executes a statement a fixed number of times. The syntax to declare a repeat loop is: 

repeat (expression) statement; 

expression - The expression can be any valid Vera expression, including constants. 

statement - The statement can be any valid Vera statement or block of statements. If a code block is 
used, the entire block is executed. 
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Repeal statements can be used to repeat any statement a fixed number of times. The value of the expres- 
sion is evaluated before the repetitions start. Changing a variable within the expression does not change 
the number of loops to be executed. 

Repeat statements are often used to implement a wait or pause in the simulation. For example: 

repeat (10) % (posedge CLOCK); 
This example pauses the simulation 10 clock cycles. 

5.5 For Loops 

Vera provides the for construct for creating loops. The syntax to declare a for loop is: 

for (initial; condition; increment) statement; 
initial - The initial is an assignment statement used to set the loop control variables. 
condition - The condition can be any valid Vera expression. 

increment - The increment defines how the loop control variable changes each time the loop is 
repeated. It can be any valid expression. 

statement - The statement can be any valid Vera statement or block of statements. If a code block is 
used, the entire block is executed. 

The for loop sets the initial value of the loop control variable. It evaluates the condition. If the condition 
is true, the loop executes a single time. When the loop finishes one iteration, the update expression is 
executed. Typically this expression changes the value of the loop control variable. Then the condition is 
checked again and the process continues. The loop continues as long as the condition evaluates to true. 
When it does not evaluate to true, the loop stops and control is passed to the first line of Vera code after 
the loop. 

You can specify multiple variables in the initial statement, separating them with commas. Multiple vari- 
ables can also be used in the condition expression. These variables (with their initialized values) are 
passed to the loop and can be used within the loop for loop control or in Vera expressions. 

Vera does not allow assignments within the conditional. The conditional c=l is invalid. Instead, you 
must use c==l. 

These are some examples of Vera for loops: 

for ( count =0 ; count<3 ; count=count+l) 

value=value+ ( (a [count] ) * ( count* 1) ) ; 

£or(count=0, done=0, i=0; i*count<125; i++) 
printf ('Value i = %d\n*,i); 
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5.6 While Loops 

Vera provides the while construct for creating loops. The syntax to declare a while loop is: 

while [condition) statement; 
condition - The condition can be any valid Vera expression. 

statement - The statement can be any valid Vera statement or block of statements. If a code block is 
used, the entire block is executed. 

The loop iterates while the condition is true. When the condition is false, control passes to the first line 
of Vera code after the loop. The condition is checked at the top of each loop. 

Vera does not allow assignments within the conditional. The conditional c=l is invalid. Instead, you 
must use c==l. 

This is an example of a while loop: 

operator =0; 

whi le ( operator < 5 ) { 

operatbr=operator+l; 

print f ( "Operator is %d*, operator); 

) 

This loop continues until operator equals 5. Each time through the loop, operator is increased by 1 . The 
check is made at the top of each loop. After 5 passes through the loop, the loop ends, and control is 
passed to the first line of code after the loop. 

If the condition is a non-zero constant, the loop becomes infinite. Infinite loops can only be broken us- 
ing the break statement (see Section 5.7.1, "Break"). 

5.7 Break and Continue 

Vera provides the break and continue statements for flow control within loops. 

5.7.1 Break 

The break statement is used to force the immediate termination of a loop, bypassing the normal loop 
test The syntax to declare a break is: 

break; 

When the break statement is executed from inside a loop, the loop is immediately terminated and con- 
trol passes to the first line of Vera code after the loop. If the break statement is executed outside of a 
loop, a syntax error is generated. 

This is an example of the break statement: 
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while (test_flag) { 
if (done) break; 

} 

This example breaks if the condition is satisfied. Control returns to the first line after the loop. 

5,7.2 Continue 

The continue statement forces the next iteration of a loop to take place, skipping any code in between. 
The syntax to declare a continue statement is: 

continue; 

In a repeat loop, the continue statement passes control back to the top of the loop. If the loop is com- 
plete, control is then passed to the first line of code after the loop. 

In a for loop, the continue statement causes the conditional test and increment portions of the loop to 
execute. 

In a while loop, the continue statement passes control to the conditional test 
This is an example of a continue statement: 

for (i=0;i<10;i++) { 

if (skip_loop) continue; 

} 
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6. Concurrent Control 

This chapter discusses how Vera handles concurrency. It explains how to model parallel, independent 
activities and details the Vera constructs used to control those concurrent threads. It includes these sec- 
tions: 

• Fork and Join 

• Events 

• Semaphores 

• Regions 

• Mailboxes 

• Timeout Limit 

• Backward Compatibility 

6.1 ForkandJoin 

Fork/join blocks provide the primary mechanism for creating concurrent processes. The syntax to de- 
clare a fork/join block is: 

fork 

{statementl; } 
{statement2; } 
(...) 

{statementN; } 
join wait^option 

statementN - The statements can be any valid Vera statement 

waitjoption - The waiijoption specifies when the code after the fork/join block executes. The 

wait_option must be all, any, or none. The all option is the default Code after the block executes 
after all of the concurrent processes have completed. When the any option is used, code after the 
block executes after any single concurrent process is completed. When the none option is used, 
code after the block executes immediately, without waiting for any of the processes to complete. 
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The flow for a fork/join block is shown in Figure 6-1. 



( fork ) ( fork ) 



(join [all] ) 



Q join any ^ 



Figure 6-1 Fork/Join Flow Diagram 
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fork 



C 



1 



joxn none 



Note - When defining a fork/join block, do not encapsulate the entire fork 
inside braces ({ }). Doing so results in the entire block being treated as a 
single process, and the code executes consecutively. For example, avoid this 
construct: 

fork { 

{statement!.;} 
{statement 2 ; } 

} 

join 



This is an example of a basic fork/join construct: 

fork 
{ 

61,100 foojbus.ack == 1'bO; ' : 

printf CFirs.t Block: foo_bus.ack is driven\n"); 

} ' ' 

( 

65 foo_bus.req = 1'bO; 
61 foojous.req <= l'bl; 

printf ( 'Second Block : f oo_bus . req is driven\n* ) ; 
} 

join 
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The concurrent block executes all the statements in parallel. The beginning of each statement is execut- 
ed at the same point in time. Subsequent statements are executed based on any timing considerations . 



6.1.1 Fork and Join Control 

Vera provides several constructs to control fork/join blocks. Vera uses the wait_child()» wait_var(), and 
terminate constructs to wait for the completion of processes and stop the execution of processes. Vera 
also includes the suspend_threadO system task to temporarily suspend threads. 



The wait_child(3 system task is used to ensure that all child processes are executed before the Vera pro- 
gram terminates. The syntax is: 

wait_child<) ; 

By default. Vera terminates a simulation when the end of the program is reached, regardless of the sta- 
tus of any child processes. Using the wait_childO task causes Vera to wait until all the child processes 
in the current context are completed before executing the next line of code. 

This is an example of a program using the wait_child() construct: 

program test 
{ 

s tar t_moni tors () ; //Starts monitors that loop forever in background 



task s tar t_moni tors () 
{ 

fork 
(...) 
join none 



task do_test() 

.{•:.. . . ' 

//Code to do testing., 
fork 
(...) 

join ndne //Creates child processes that take an indeterminate amount 

//of time to complete '■ . r " - • 

wait_child() ; 

) ' * 



within the process. 



6.1.1.1 wait.childQ 



do_test<); //Performs the actual test 



■ r 
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This example calls two separate tasks. The do_tes t task forks off several child processes that take an 
indeterminate amount of time to complete. The wait_child() call waits for the threads called in the 
do_test task to complete before executing subsequent Vera code. Note that the wait_child() call does 
not wait for any child processes created outside of its context. 

6.1.1.2 wait_var() 

The wait_varO system task blocks the calling process until one of the variables in its arguments list 
changes values. The syntax is: 

wait_var ( vari abl es ) ; 

variables - The variables are one or more variables (separated by commas) of type integer, bit, string, 
array, or enumerated type. 

The wait_var() task blocks the current process until one of the specified variables changes value. Only 
true value changes unblock the process. Reassigning the same value does not unblock. If more than one 
variable is specified, a change to any of the variables unblocks the process. 

This is an example of the wait_varO task: 

bit [7: 0 3 data [100]; 
integer i; 

fork 
{ 

wait_var (data [2 ) ) ; 

printf <*Data[2J has changed to: %d\n", data[2]); 

) 
{ 

for (i=0;i<100; i++) 
{ 

data [ i ) =random ( ) ; 
e (posedge CLOCK) ; 

} 

} 

join 

This example forks off concurrent processes. The first thread is suspended until the second element of 
array data is changed. The second process randomly changes the values within array data. When da- 
tall] is changed, the first process prints its message. 

6.1.1.3 terminate 

The terminate statement terminates all active descendants of the process in which it was called. The 
syntax is: 
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terminate ; 

If any of the child processes have other descendants, the terminate command terminates them as well. 
If used at the top level, terminate terminates all child processes. When the main program is completed. 
Vera executes an implicit terminate statement 

This is an example of how terminate is used within a simple fork/join block: 

task do_test() 
{ 

// Code to do testing 

fork 

(...) 

join any// Creates child processes that take an indeterminate amount of 

//time to complete 
// Code to do more testing 
terminate ; 

) 

This example forks off several child processes within a task. After any of the child processes is com- 
plete, Vera continues to execute code. Before the task is completed, all remaining child processes are 
terminated. 

6.1.1.4 suspend_thread() 

The suspend_threadO system task is used to temporarily suspend the current thread. The syntax is: 
0uspend_thread ( ) ; 

The suspend_threadO system task temporarily suspends the current thread and allows other ready con- 
current threads to run. When the other threads are done, the suspended thread resumes execution. For 
example: 

for <i=0;i<10;i++) 
{ 

" fork ■" : : '^>*- 

my_task(i) ; * *' 

join none 
suspend_thread ( ) ; 

} 

This example forks multiple threads calling my_task. The thread is forked, the task is called, and then 
the thread is suspended. The next iteration of the loop occurs and forks the next thread. That thread be- 
gins execution and is suspended. All 10 threads are created, begin execution, and are suspended. Con- 
trol returns to the first thread, and then each is executed in sequence. Using this construct, you do not 
need to declare i as a shadow variable. 
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Note - Suspended threads execute after all other current threads execute. 
However, relative to simulation lime, the thread is still executed concurrently 
with the other threads. 



5 s 



6.1.2 Shadow Variables 

By default, all child processes have access to the parent's variables. However, if multiple processes in- 
dependently write to the same variable, races can occur. To avoid races within fork/join blocks, Vera 
uses shadow variables. The syntax to declare a shadow variable is: 

shadow datatype variable_name; 

Using the shadow keyword forces the Vera compiler to create a copy of the variable local to each child 
process, which eliminates race conditions. 

This is an example of how shadow variables are used: 

shadow bit [31:0] address; 
shadow bit 131:0] data; 
integer i; 

for (i=0; i<num_try; i++) 
{ 

repeat ( random ( ) %MAX_DELAY ) ©(CLOCK) ; 
address =random( ) ; 
data=random() ; 

printf {*Random access with Addr:%h Data%h\n*, address, data) ; 



III fork 



Memory_Access (address, data) ; 
) 

join none 
) 



This example declares the variables address and data as shadow variables. The for loop then randomiz- 
es these variables and forks off a child process that calls the function Memory_ J Access with address 
and data as parameters. The loop continues without waiting for the child process to complete because of 
the join none statement. The shadow variables must be used in this instance; to ensure that the call to 
Memory_Access is made with variables that have not been re-randomized by subsequent loops. 



6.2 Events 



Events are variables that synchronize concurrent processes. When a sync is called, a process blocks un- 
til another process sends a trigger to unblock it Events act as the go-between for triggers and syncs. 
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6.2.1 Triggers 

Triggers are used to send events. The syntax to call a trigger is: 

trigger ( t trigger^type. ] event_name) ; 
trigger Jype - Table 6-1 lists the trigger types with a brief definition. 
Table 61 Trigger Types 



Trigger Type 



Action 



ONE_SHOT Triggers pending syncs (default) 

ONE BLAST Like ONE_SHOT, but it includes all syncs in the current cycle 

HANELSHAKE Triggers the oldest pending sync, or queues request 

ON Turns on the event 

OFF Turns off the event 



eventjname - The event _name is the name of the event being triggered. 



ONE.SHOT 

The ONE_SHOT trigger is the default trigger type. If you use a ONE_SHOT trigger, any process wait- 
ing for a trigger receives it If there is no process waiting for the trigger, the trigger is discarded. 



PROCESS 1 


syncl 


/ 




PROCESS 2 


sync2 






PROCESS 3 


Trigger 



Figure 6-2 ONE_SHOT Triggers 

There is a danger when using ONE.SHOT triggers. Figure 6-2 shows a trigger called in process 3. The 
trigger unblocks syncl. However, because the trigger and sync2 execute simultaneously, whether or 
not process 2 is unblocked depends on the execution order. The sync must be called before the trigger 
is executed when using ONE.SHOT triggers. If the sync is called after the trigger is executed, the pro- 
cess will wait indefinitely. 
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ONE_BLAST 

ONE_BLAST triggers work just as ONE_SHOT triggers with the exception that they trigger any sync 
called within the current cycle, regardless of whether or not it was called before the trigger was execut- 
ed. If a ONE_BLAST trigger is used for the situation diagrammed in Figure 6-2, all the processes are 
unblocked regardless of execution order. 

HAND_SHAKE 

HAND_SHAKE triggers unblock only one sync, even if multiple syncs are waiting for triggers. If a 
sync has already been called and is waiting for a trigger, the HAND_SHAKE trigger unblocks the sync. 
If no sync has been called when the trigger occurs, the HAND_SHAKE trigger is stored. When a sync 
is called, the sync is immediately unblocked and the trigger is removed. 

ON 

The ON trigger is used to turn on an event. An event cannot be used to synchronize concurrent process- 
es if it is not turned on. 

OFF 

The OFF trigger is used to turn off an event An event cannot be used to synchronize concurrent pro- 
cesses if it is turned off. 

6.2.2 Sync 

The syncO system task synchronizes statement execution to one or more triggers. The syntax to call the 
syncO task is: 

sync (sync_type, eventl , event2 4 ... eventN) ; 
syncjype - The possible sync types and their definitions are listed in Table 6-2. 



Table 6-2 Sync Types 



Sync Type 


Definition 


ALL 


Waits until all events are triggered 


ANY 


Waits until any event is triggered 


ORDER 


Waits until all events are triggered in the 




specified order 


CHECK 


Checks if all events are ON 



eventN - The event is the event variable name on which the sync is activated. 
ALL 

The ALL sync type suspends the process until all of the specified events are triggered. For example: 
sync (ALL, event_a , event_b, e ventre) ; 
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This example suspends the thread until each of the events are triggered. Once they are triggered, the 
statement immediately following the sync() call is executed. 

ANY 

The ANY sync type suspends the process until any of the specified events is triggered. For example: 

sync (ANY. event_a. event_b, event_c) ; 
This example suspends the thread until any of the specified events is triggered. Once one of the events 
is triggered, the statement immediately following the syncO call is executed. 

ORDER 

The ORDER sync type suspends the process until all of the specified events are triggered in the given 
order. For example: 

sync (ORDER, event_a, event_b, event_c) ; 

This example suspends the thread until all of the specified events are triggered. As soon as an event is 
received out of order, the process unblocks and a simulation error occurs. Also, only the first event can 
be in the ON state when the sync is called. If both event_a and event_b are ON when the call is 
made, a simulation error occurs. 

Note - Events that are set to NULL are always treated as if they were 
received in the correct order. 



CHECK 

The CHECK sync type is called as a function. It does not suspend the thread. It returns a 1 if the trig- 
ger is ON and a 0 if it is not This sync type can only be used with ON and OFF trigger types. This sync 
type can only be used with a single event per call. For example: 

if (sync (CHECK, event_a) ) . 

printf ( "The . event i6 ON.\n*); 

This syncO call returns a 1 if the event is on, and then prints the message. If the event is OFF. a 0 is re- 
turned. 



6.2.3 Event Variables 

Event variables serve as the link between triggers and syncs. They are a unique data type with several 

important properties. 
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6.2.3.1 Bidirectional Event Variables 

Event variables are bidirectional variables when used as arguments in syncs and triggers. The same 
event variable can be used to pass and receive triggers. For example: 

- task foo (event trigger_a) 
{ 

printf C\nFOO syncing at cycle=%0d' , get_cycle ( ) ) ; 

sync (ALL, trigger_a) ; // Blocked: proceed after receiving trigger 
printf ("\nFOO event trigger_a received at cycle=%Od',get_cycle() ) ; 
repeat (5) ©(posedge CLOCK); 

printf C \nFOO triggering trigger_a at cycle=%0d" , get_cycle() ); 
trigger (trigger_a) ; 

} 

program trigger_play 
{ 

event trigger 1 ; 
breakpoint; 

// top block code starts here 
fork 

foo(triggerl) ;// start foo and go on 
join none 

repeat(8) G(posedge CLOCK); //foo is blocked waiting for event trigger 
fork 

printf C \nPROGRAM triggering triggerl ecycle=%0d- , get_cycle ( ) ) ; 
printf C \nPROGRAM This unblocks f ©ou- 
trigger (triggerl) ; // unblock the waiting foo 

{ ■ * - .. 

repeat (7) ©(posedge CLOCK); 

printf ( " \nPROGRAM syncing ecycle=%0d\n\n* , : - getlcycle ( ) ) ; 
sync (ALL, triggerl) ;// wait for foo to unblock me 

) / v ■ . ' .... 

join 

wait_child() ; 

printf ( "Trigger play done! • ) ; 

} 

This example declares the task foo, which is called in the main program. Then foo is called in a thread 
forked off from the main program. The program continues without waiting for the child process to com- 
plete. Because foo contains a sync within its definition, the child process blocks, waiting for a trigger. 
Then another fork is used to fork off a trigger, which unblocks the suspended foo. A second process in 
that fork then calls a sync. This sync occurs as foo is unblocked. Foo then continues its execution, 
which includes the execution of the trigger that unblocks the final child process. 



# 
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6.2.3.2 Disabling Events 

If an event variable is assigned a null value, the event is ignored in subsequent syncO calls that may be 
waiting for a trigger on the event variable. For example: 

event boo = null; 
sync (ALL, boo); 

The sync is immediately satisfied because of the null value assigned to boo. 



6.2.3.3 Merging Events 

When an event is assigned to another event, the two are merged, which causes triggers on either one to 
affect both. For example: 

event boo, foo, woo; 
boo = foo; 
trigger (boo) ; 

trigger(boo) ; // this will trigger foo, as well 
trigger(foo) ; // this will trigger boo, as well 
boo = woo; 
foo = boo; 

trigger (boo) ; // this will trigger foo and woo, as well 
trigger (foo) ; // this will trigger boo and woo, as well 
trigger (woo) ; // this will trigger boo and foo, as well 

However, use caution when merging events. The assignment affects subsequent triggers and syncs. For 
example, if a process is blocked waiting for eventl when you assign another event to eventl, the 
sync will never unblock. For example: 

fork 

{ . . • -r ■ r: 

while (1) {sync (ALL, foo);) 

{ 

while (1) {sync (ALL, boo);} 

) ' ' . ■ ' ' ' . 

{ 

foo = boo; ' ' " 

while (1) {trigger (foo);) 

) 

join • .7 "\ 



:.-*t...' 
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This example forks off three concurrent threads. Each starts at. the same time in the simulation. So, at 
the same lime that threads 1 and 2 are blocked, thread 3 assigns the event boo to f oo. This means that 
thread 1 can never unblock, because the event f oo is now boo. To unblock both threads 1 and 2, the 
merger of f oo and boo must take place before the fork. 



6.3 Semaphores 

A semaphore is a primitive operation used for mutual exclusion and synchronization. 
The semaphore system functions are: 

alloc ( SEMAPHORE , semaphore_id, semaphore^ ount [, key_count] ) ; 
semaphore je t {wait_option t semaphore^ d , key_wei ght) ; 
8emaphore_put {semaphore^id, key^weight) ; 



6.3.1 Conceptual Overview 

Conceptually, semaphores can be viewed as a bucket When you allocate a semaphore, you create a vir- 
tual bucket. Inside the bucket are a number of keys. No process can be executed without first having a 
key. So, if a specific process requires a key, only a finite number of occurrences of that process can be 
in progress simultaneously. All others must wait until a key is returned to the virtual bucket 

6.3.2 allocO 

To allocate a semaphore, you must use the allocO system function. The syntax is: 

alloc (SEMAPHORE, semaphore_id t semaphore_count [ , key_count} ) ; 

semaphore Jul - The semaphore Jul is the ID number of the particular semaphore being created. It must 
be an integer value. You should generally use 0. When you use 0, Vera automatically generates a 
semaphore ID. 

semaphore jcount - The semaphore jcount specifies how many semaphores you want to create. It must 
be an integer value. 

key jcount - The key jcount specifies the number of keys allocated to each semaphore. 

The allocO function returns the base semaphore ED if the semaphores are successfully created. Other- 
wise, it returns 0. 

The maximum number of semaphores that can be created is determined by a runtime parameter. See 
Section 18.5, "Running Vera with HDLs." 



6.3.3 semaphore _get() 

To check that there are enough keys left in the semaphore, you must use the semapho re_get0 system 
function. The syntax is: - 

— T 
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fiemaphore_get (wait^ option, semaphore^id, key_weight) ; 

wait_option - The wail option can either be NO.WAIT or WAIT. The NO.WAIT option continues 
code execution if there are not enough keys available. The WAIT option suspends the process until 
there are enough keys available, at which time execution continues. 

semaphore Jd - The semaphore Jd specifies which semaphore to get keys from. 

keyjweight - The key_weight specifies the number of keys being taken from the semaphore. 

When the semaphore_getO function is called, it checks the specified semaphore for the number of re- 
quired keys. If there are enough keys available, a 1 is returned and execution continues. If there are not 
enough keys available, a 0 is returned and the process is suspended depending on the wait option. 

The semaphore waiting queue is FIFO based. By default, a process will wait at a semaphore without 
timing out Users can set a time limit with the timeoutO system task. See Section 6.5.5, "Mailbox Ex- 
ample." 

If multiple semaphores are allocated, you can access the Nth semaphore using this method: 

semID=alloc (SEMAPHORE, 0, 4, 2); 

if (semaphore_get (WAIT, semID+2, 1)) 

print f ( *The semaphore was successful . * ) ; 

This example allocates four semaphores with IDs 0 to 3, each with two keys. Then it checks to see if 
there is a key in the third semaphore. If there is, a message is printed. 

6.3-4 semaphore_put() 

To put keys back into a semaphore, you must use the semaphore_putO system task. The syntax is: 

■emaphorejrut ( semaphore_id, keyjweight); 

semaphore Jd - The semaphore Jd specifies which semaphore to return the keys to. 

key _w eight - The keyjweight specifies the number of keys being returned to the semaphore. 

When the semaphore_putO system task is called, the specified number of keys is returned to the sema- 
phore. If a process has been suspended to wait for a key, that process executes when enough keys have 
been returned. 

6-3.5 Semaphore Example 

This is an example of basic semaphore usage: 

class gen 
{ 

local reg[2:0] bit_f ield^a; 

static integer gu = alloc (SEMAPHORE, 0. 1..1); 
task ml() '* ' * ' -■ 
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{ 

printf(*The value of guard %0d, in gen\n" , gu) ; 

) 

task new() 
{ 

bit_field_a = randomO; 

} 

} 

program test 
{ 

integer i, j; 
gen gl f g2 , g3; 

printf(*This is program test beginning. \n") ; 
gl=new ; g2 =new ; g3 =new ; 

printfCThe gnd in main %0d %0d %0d\n* , gl.gu, g2.gu, g3.gu); 

fork 

{ 

©(posedge CLOCK) ; 
semaphore„get(WAIT, gl.gu, 1) ; 

printf(*This is gl semaphore_get at cycle %0d\n" , get_cycle ( ) ) ; 
repeat (2) ©(posedge CLOCK); 
semaphore_put (gl .gu, 1) ; 

} 
{ 

©(posedge CLOCK); 
semaphore_get (WAIT, g2 .gu, 1) ; 

printf(*This is g2 semaphore_get at cycle %0d\n*, get_cycle ( ) ) ; 
repeat (2) e (posedge CLOCK); 
semaphore^ put (g2 .gu, 1); 

} 
{ 

0 (posedge CLOCK); /■ ' 

semaphore_get (WAIT, g3.gu, 1); 

printf( m This is g3 semaphore_get at cycle %0d\n*, get_cycle ( ) ) ; 
repeat (2) ©(posedge CLOCK); 
semaphore_put (g3 .gu, 1); 

} ' : 

join all 

} 

This example creates class gen inside which a single semaphore is allocated with 1 key. Within the 
main program, g] t g2, and g3 are instantiated. These are instances of the class gen. However, there is 
only one semaphore because of the static declaration in the semaphore allocation. Then the main pro- 
gram forks off three separate threads. Each thread tries to get a key from the semaphore. If it is unable, 

-IT ^* ; 
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it wails until a key is available. Once it gets the key, it prints a message, advances the simulation clock, 
and returns the key to the semaphore. In this way, each thread is suspended until a semaphore key is 
available, which can be used to prevent conflicts between threads. 



6.4 Regions 

A region is a mutual exclusion mechanism that guarantees that the requested values are unique in the 
simulation. This feature is provided mostly for random type simulations that may depend on the unique- 
ness of specific values such as addresses or data-IDs. 

The region system functions are: 

alloc (REGION, region__id, region^count) ; 

reglon.enter [wait_option t region_id. valuel, valued valueN) ; 

region_exit (region^id, valuel, value2. . . . , valueN) ; 

6.4.1 Conceptual Overview 

Conceptually, regions can be viewed as a set of letters. First you allocate which letters are included in 
the seL These letters are the only letters from which words can be made. If one person uses the letters 
to spell CAT, no one else can spell TIN because the T is already in use. Once the T is returned, TIN can 
be created. Effectively, this ensures that data sets are unique, and it eliminates concurrent crossover. 

6.4.2 allocO 

To allocate a region, you must use the allocO system function. The syntax is: 

alloc (REGION, region_id, region_count) ; 

region Jd - The region Jd is the ID number of the particular region being created. It must 

be an integer value. You should generally use 0. When you use 0, Vera automatically generates a 
region ID. 

region jcount - The region jcount specifies how many regions you want to create. It must 
be an integer value. 

The allocO function returns the base region ID if the regions are successfully created. Otherwise, it re- 
turns 0. 

The maximum number of regions that can be created is determined by a runtime parameter. See 
Section 18.5, "Running Vera with HDLs" 

6.4.3 region.enterO 

The region.enterO system function checks to see if a particular region is in use. The syntax is: 
reaiax^«nt«r(wait_option, region^id. valuel. value2, . . . # _jra ljgeN) ; 
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waitjoption - The wait option can either be NO.WAIT or WAIT. The NO.WAIT option continues 
code execution if the specified region is in use. The WAIT option suspends the process until 
the specified region is no longer in use. 

regionjd - The region Jd specifies which region that is being entered. 

valueN - The values are integer or bit vectors up to 64 bits, without X's or Z's. These values specify 
the unique region values. 

The region.enterO system function checks the specified values against all region values for the speci- 
fied region. If another process has entered the region with one or more of the values, then those values 
are in use, and the current region cannot use them. If none of the values are in use elsewhere, the func- 
tion returns a 1, flags the values as in use, and passes control to the next line of code. If one or more of 
the values is in use elsewhere, the function suspends the current thread until the values become avail- 
able, depending on the wait option. 

The region waiting queue is FIFO based. By default, a process will wait at a region without timing out. 
Users can set a time limit with the timeoutO system task. See Section 6.5*5, "Mailbox Example." 

6.4.4 region_exit() 

The region_exitO system task removes the specified values from the in-use state. The syntax is: 

region_exit (region_id, valuel, value2, valueN) ; 

regionjd - The regionjd specifies which region that is being exited. 

valueN - The values are integer or bit vectors up to 64 bits, without X's or Z's. These values specify 
the unique region values. 

When the regjon_exitO system task is called, the specified values are no longer in use and can be used 
in other regions. Any processes that are suspended waiting for region values execute when the region 
values are made available. 

6.4.5 Region Example 

This is an example of region usage: 

task CPU (integer id, integer grant, integer regID) 
{ 

integer data, address; 
bit (31:0] randVar; 

repeat (256) { 

randVar= random ( ) ; 
address =randVar [13:61; 
. da ta=randVar (29:22] ; 
region_enter (WAIT, regID, address); 
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. 61 memsys. request (id]=l'bl; 
32,20 memsys. grant==grant; 
writeOp (address, data) ; 
61 memsys .request [id) =l*b0; 
62,20 memsys . grant ==2 ' bOO ; 
61 memsys. request [id] =l'bl ; 
62,20 memsys . grant ==grant ; 
r eadOp ( addres s , data ) ; 
61 memsys. request [id] =l'b0 ; 
62,20 memsys. grant ==2 'b00; 
region_exit (regID, address); 
repeat (randVar [20: 17] )6(posedge memsys. elk) ; 

) 

) 

regID=alloc (REGION, 0, 1) ; 
fork 

CPU(0, 2'b01, reglD); 
CPU(1, 2'blO, regID) ; 
join 

This example repeats a loop 256 times. Within the loop, first a random 32 bit value is generated and as- 
signed to randVar. Then a random address and random data are assigned to address and data. Next, the 
region.enterO call checks to see if the address is in use. If it is in use, the process suspends until the 
value is freed. When the value is not in use; execution continues until the region is exited. 

6.5 Mailboxes 

A mailbox is a mechanism to exchange messages between processes. Data can be sent to a mailbox by 
one process and retrieved by another. 

The mailbox system functions are: 

alloc (KAXXiBOX, mailbox^ld, mailbox^count) ; , zi : 

m&ilbox_put (mailbox^id, data) ; 

mailbax_jg«t(wait_opcion, maxlbox_id (, dest_var [, check^optionl J); 

6.5.1 Conceptual Overview 

Conceptually, mailboxes behave like real mailboxes. When a letter is delivered and put into the mail- 
box, you can retrieve the letter (and any data stored within). However, if the letter has not been deliv- 
ered when you check the mailbox, you must choose whether to wait for the letter or retrieve the letter 
on subsequent trips to the mailbox. Similarly, Vera f s mailboxes allow you to transfer and retrieve data 
in a very controlled manner. 
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6.5.2 allocO 

To allocate a mailbox, you must use the alloc() system function. The syntax is: 
alloc (MAILBOX, mailbox_id, mailhox_coxint) ; 

mailbox Jd - The mailbox Jd is the ID number of the particular mailbox being created. It must 

be an integer value. You should generally use 0. When you use 0, Vera automatically generates a 
mailbox ID. 

mailbox jcount - The mailbox_count specifies how many mailboxes you want to create. It must 
be an integer value. 

The allocO function returns the base mailbox ID if the mailboxes are successfully created. Otherwise, it 
returns 0. 

The maximum number of mailboxes that can be created is determined by a runtime parameter. See 
q Section 18.5, "Running Vera with HDLs." 

Q 5 6.5.3 mailbox_putO 

■=? The mai!box_put() system task sends data to the mailbox. The syntax is: 
fn ma.ilbox__put {mailbox_id t data); 

" " mailbox Jd - The mailbox Jd specifies which mailbox receives the data. 

5=- data - The data can be any general expression that evaluates to a scalar. This includes all data types 
f~ discussed in Section 3.2, "Data Types and Variable Declaration." 

0J The mailbox_put() system task stores data in a mailbox in a FIFO manner. 

~ e Note - mailbox_putO can ONLY be used with mailbox_get(). Using 

maflbox_putO with mailbox_receive0 results in a runtime error. 



6.5.4 mailbox getQ 

The mailbox_getO system function returns data stored in a mailbox. The syntax is: 

nailbox_jgot (waic_opc ion, mailbox_id [, dest_var t, check_option] ]); 

waitjoption - The wail option can either be NO_WAIT or WAIT. The NO_WAIT option continues 
code execution if the mailbox is empty. The WAIT option suspends the process until a message . 
is sent to the mailbox. 

mailbox Jd - The mailbox Jd specifies which mailbox data is being retrieved from. 

destjvar - The destjvar is the destination variable of the mailbox data. 
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check _option - The checkjoption is an optional argument that should be set to CHECK when used. It 
specifies whether type checking occurs between the mailbox data and the destination variable. 

The mailbox_get0 system function assigns any data stored in the mailbox to the destination variable 
and returns the number of entries in the mailbox, including the entry just received. If there is a type 
mismatch between the data sent to the mailbox and the destination variable, a runtime error occurs un- 
less the CHECK option is used. If the CHECK option is active, a -1 is returned, and the message is left 
in the mailbox and is dequeued on the next mailbox_getO function call. If the mailbox is empty, the 
function waits for a message to be sent, depending on the wait option. If the wait option is NO_WAIT f 
the function returns a 0. 

If no destination variable is specified, the function returns the number of entries in the mailbox, but it 
does not dequeue an item from the mailbox. 

For example, this can be used to continue generating mailbox entries, until a specified number are gen- 
erated: 

mboxID=alloc (MAILBOX ,0,1); 
while (mailbox_count <11) 
{ 

mb_data=random() ; 
mailbox_put (mboxID, mb_data) ; 
mailbox_count=mailbox_get (NO_WAIT, mboxID) ; 

} 

This example generates random numbers and puts them in the mailbox. The loop continues while the 
number of entries is less than 11. 

The mailbox waiting queue is FIFO based. By default, a process will wait at a mailbox without timing 
out Users can set a time limit with the timeoutQ system task. See Section 6.5.5, "Mailbox Example." 



6.5.5 Mailbox Example 

This is an example of basic mailbox usage: 

mboxID=alloc (MAILBOX,. 0, 1); .., 
fork 

{ repeat (256) 

{ r andomVar = random ( ) ; 

address () =randVar [ 17 : 0 ] ; 

61 memsys. re<iuest(0]=l,bl; 

62,20 memsys . grant ==2 ' bOl ; 

data0=randVar [7 : 0 ] ; 

writeOp ( address 0, dataO); 

mailbox_put (mboxID, {addressO, dataO}); 

61 memsys. request 10] =1 *b0; 

62,20 memsys. grant==2'b00; 
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random_wait ( ) ; 

) 

} 

{ repeat (25 6) 

{ mb_var=mailbox_get (WAIT, mboxID, message, CHECK); 
address l=mes sage [15 : 8] ; 
datal=message [7 : 0] ; 
61 memsys. request [1]=1 *bl; 
62,20 memsys. grant ==2' blO ; 
readQp(addressl,datal) ; 
61 memsys. request [l]=l'b0 ; 
62,20 memsys . grant ==2 ' bOO ; 
random_wait ( ) ; 

) 

} 

join 

This example allocates a mailbox before the fork. The first thread then randomly assigns values to 
addressO and dataO. The data is then passed through a mailbox to the second thread, which is waiting 
for the data. That data is read into message and used for the readOp call. 

6.6 Timeout Limit 

A process will wait forever in semaphore, region and mailbox if the waiting resources are not available. 
However, the system task timeoutO can be used to set a time limit The syntax is: 

timeout (object, type, cycle^limit [, objected}) ; 

object Jype - The object Jype specifies the type of object for which the timeout is defined. It must be 
EVENT, SEMAPHORE, REGION, or MAILBOX. 

cycle Jimit - The cycle Jimit specifies the maximum number of cycles any request will wait. 

object Jd - The object Jd specifies an individual resource for which the timeout is set If it is not 
specified, the timeout exists for all objects of the type specified. 

When the timeoutO system task is used, it sets the maximum number of cycles that an object will wait 
for a request The cycles are based on the SystemClock. If the cycle limit is set to 0 cycles, the tim- 
eout is disabled. You can specify a timeout for a specific event or for all events of a certain type. 

When a semaphore, region, or event times out, a verification occurs. 

These are examples of timeout statements 

t imeou t ( SEMAPHORE , 100); 
timeout (REGION, 50, r_ID) ; 
timeout (EVENT, 20); 
timeout (my event , 300); 



Synops^slno. 



Vera 4.0 User's Manual 



Chapter 6. Concurrent Control 131 



Note - Specific timeouts take precedence over global timeouts. 



6.7 Backward Compatibility 

Versions of Vera prior to Vera 4.0 used different commands for mailbox usage: mailbox_send0 and 
mailbox_receiveO- 

6.7.1 mailbox_send() 

The mailbox_sendO system task sends data to the mailbox. The syntax is: 

mailbox_Bend {mailbox_id. data); 
mailbox Jd - The mailbox Jd specifies which mailbox receives the data. 
data - The data can be an integer or bit vector of any size. 
The mailbox.sendO system task stores data in a mailbox in a FIFO manner. 

Note - mailbox_send() can be used with either mailbox.receiveO or 
mailbox_getO- 



6.7.2 mailbox_receiveO 

The mailbox.receiveO system function returns data stored in a mailbox. The syntax is: 

mailbox_receive(fcrait_option, mailbox^id) ; 

waUjopdon - The wait option can either be NOJWAIT or WAIT. The NO_WAIT option continues 
code execution if the mailbox is empty. The WAIT option suspends the process until a message 
is sent to the mailbox. 

mailbox Jd - The mailbox Jd specifies which mailbox data is being retrieved from. 

The mailbox_receiveO system function returns the data stored in the mailbox if there is any. If the 
mailbox is empty, the function waits" for a message to be sent, depending on the wait option. If the wait 
option is NO.WAIT, the function returns a 0 and sets the error flag (see Section 7.3.1, "Error Handling" 
for information on error flags). 

The mailbox waiting queue is FIFO based. By default, a process will wait at a mailbox without timing 
out. Users can set a time limit with the timeoutQ system task. See Section 6.5.5, "Mailbox Example " 
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Example 2: Flow Control 



This is an example of the arbiter in Example 1. The example includes these features: 

• Fork and join 

• Triggers 

• Semaphores 

• Regions 

• Mailboxes 

This example includes these files: 

• arbAf.vr 

• signal_drive.vr 

• RUN (a run script) 



# define OUTPUT.SKEW #1 
tdefine INPUT_EDGE P SAMPLE 

interface arb 
{ 

output [31:0] mem_addr PHOLD OUTPUT_SKEW; 

inout [15:0] mem_data INPUT_EDGE PRZ OUTPUT_SKEW vca rz; // vca monitor 

output oe PHOLD OUTPUT_SKEW; 

output ce PHOLD OUTPUT_SKEW; 

input ack INPUT_EDGE vca rO; // vca monitor 

input elk CLOCK; 

} 

port generic_port 



addr; 

data; 

oe; 

ce; 

ack; 



arb.if.vrh 



> 



bind generic_port port_a 
{ 

addr arb. mem. addr; 
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data arb.mem_data; 
oe arb . oe ; 
ce arb.ce; 
ack arb.ack; 

} 

bind generic_port port_b 
{ 

addr arb . mem_addr ; 
data arb.mem_data; 
oe arb . oe ; 
ce arb . ce ; 
ack arb.ack; 



signal_drive.vr 

# include <vera_def ines . vxh> 
# include •arb.if.vrh* 
tdefine RSEED 32 'hl234_5678 
# define MB_ID_A 0 
tdefine MB_ID_B 1 

// modified from ch4_ex to use semaphore as an arbiter 
// to directly access the memory 

// port_a and port_b are used to access write- read sequences 
// region — enter/region_exit is deployed to protect memory 
// address being used by a either port not to be corrupted 
// by the other 

// mailbox are use to pass address information from the write 
// process to read process 

// trigger and sync are used for illustrative to signal the 
// end of processes 

program signal_test 
{ 

integer sem_id; // global semaphore 
integer reg_id; // global region 
integer mbox_id[2 3; // global mailbox 
integer rands eed = RSEED; 
event evt[4); // global events 
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// reset the oe and ce 
80 arb.ce <= 1'bO ; 
80 arb.oe = 1'bO ; 

// turn vca on for unexpected signal changes 

vca ( ON, arb ) ; 

// allocate 1 semaphore with initial value of 1 

sem_id = alloc ( SEMAPHORE, 0, 1, 1 ); 

if ( sem_id == 0 ) error ( •semaphore allocation failed!'); 

allocate 1 region 
reg_id = alloc ( REGION, 0, 1 ) ; 

if ( reg_id == 0 ) error ( "region allocation failed!'); 
initiate burst write-read with both port_b and port_a at the same time 

fork 
{ 

// port b 

integer i; 
bit [31:0] addr; 
bit [15:0] data[4); 

repeat (10) 
{ 

addr = random ( rands eed) & 32 'h0000_f f f f ; 

region_enter ( WAIT, reg_id, addr ); // protect the addr 
for ( i = 0; i < 4; i++ ) 

datati] = random ( rands eed ) ; // generate data 
do_write with port_b ( addr, data ) ; // do actual write 

// pass the addr and data to the read-process 

mailbox_put ( mbox w id[MB_ID_B] , addr ); 

mailbox_put ( mboK_id [MB_ID_B] , data[0) ); 

mailbox_put ( mbox_id(MB_ID_B] , datafl] ); 

mailbox_put ( mbox_id[MB_ID_B], data [2 3 ); 

mailbox_put ( mbox_id[MB_ID_B] , data [3] ) ; 
)//end repeat 

trigger ( ONE_BLAST, evt[0] ); // signal finish 

) 
{ 

// port_b 

integer i; 
bit [31:0] addr; 

bit [15:0] exp_data[4], data[4]; 
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repeat ( 10 ) 
{ 

mailbox__get ( WAIT, mbox_idlMB_ID_B] , addr ); //capture the addr 
do_read with port_b ( addr, data ) ; //do actual read 

// verify the data read 

for ( i = 0; i < 4; i++ ) 
{ 

// capture the expected data value 

mailbox_get ( WAIT, mbox_id[MB_ID_B] , exp__data(i] ); 
if ( data[i] !== exp_data[i] ) 

error ( "port_b transactions gives inconsistent data!\n - ); 
else 

printf ("cycle %0d: portjb data %0d OK! \n*, get_cycle ( ) , i ); 

) 

region_exit ( reg_id, addr ) ; //done with the addr 
}//end repeat 

trigger ( ONE_BI*AST , evt[l] ); // signal finish 

} 
{ 

// port a 

integer i ; 

bit [31:0] addr; 

bit [15:0] data[4]; 

repeat (10) 
{ 

addr = random ( rands eed) & 32 'h0000_f f f f ; 

region_enter ( WAIT, reg_id, addr ) ; // protect the addr 
for ( i = 0; i < 4; i++ ) 

data[i] = random ( rands eed ) ; // generate data 
do_write with port_a ( addr, data ); // do actual write 

// pass the addr and data to the read-process 

mailbox_put ( mbox_id [MB_ID _A] , addr ); 

mailbox_put ( mbox_idlMB_ ID^A] , data[0] ); 

mailbox_put ( mbox_id[MB_ID_A] , data[l] ); 

mailbox_put ( mbox_id[MB_ID_A] , data [2] ); 

mailbox_put ( mbox_id[MB_ID_A] , data [3] ); 
}//end repeat 

trigger ( ONE_BLAST , evt[2] ); //signal finish 

) 
{ 

// port_a 
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integer i; 
bit [31:0] addr; 

bit (15:0) exp_data[4], data[4]; 

repeat { 10 ) 
{ 

mailbox_get (WAIT, mbox_id[MB_ID_A] , addr) ; // capture the addr 
do_read with port_a ( addr, data ); // do actual read 

// verify the data read 

for ( i = 0; i < 4; i++ ) 
{ 

// capture the data 

mailbox_get ( WAIT, mbox_id[MB_ID_A] , exp_data[i] ); 
if ( data[i] !== exp_data[i] ) 

error ( - port_a transactions gives inconsistent data!\n"); 
else 

printf ('cycle %0d: port_a data %0d OK! \n m ,get_cycle( ) , i) ; 

} 

region_exit ( reg_id, addr ); // release the addr 
}//end repeat 

trigger ( ONE_BLAST. evt[3] ) ; // signal finish 
} 

s"^ join none 

sync ( ALL, evt[0], evt[l], evt[2] , evt[3] ); 

%,\, printf C \n All Finished \n*); 

nj }//end program 

// do_read : acquire semaphore and do burst read at the addr 
// release semaphore by the end 

task do_read with generic_port ( bit [31:0] addr, var bit [15:0] data [4] ) 
( 

// acquiring lock on to driving /sampling signals 
semaphore_get ( WAIT, sem_id, 1 ); 
61 $addr .<= addr; // drive the addr, oe, ce bits 
$oe = 1'bl; 
$ce = 1'bl; 

€2, 10 $ack == 1'bl; // ack should have come within 8 cycles 
fork 
{ 

e@0, 3 Sack == 1'bl; // ack should stay for 4 cycles 
€0 $oe <= 1'bO; // at the end, deassert oe and ce 
@0 $ce = 1'bO; 

{ 

Synopsys Inc, 



138 Example 2: Flow Control 



Vera 4.0 User's Manual 



integer i ; 

for (i = 0; i < 4; i++) // latch the data for 4 consecutive cycles 
{ 

6 (posedge CLOCK) ; 
data[i] = $data; 
}//end for 

} 

join all 

©I $oe = void; // void drive to kill one more cycle 

// releasing lock 

semaphore_put ( sem_id, 1 ) ; 
}//end do_read 

// do_write : acquire semaphore and do burst write at the addr 
// release the semaphore by the end 

task do_write with generic_port ( bit [31:0] addr, bit [15:0] data [4] ) 
{ 

// acquiring lock on to driving /samp ling signals 
semaphore_get ( WAIT, sem_id, 1 ) ; 
@0 $addr <= addr; // drive the addr, oe, ce bits 
$oe = 1'bO; 
$ce = l'bl; 

©2, 10 $ack == l'bl; // ack should have come within 8 cycles 

fork 

{ 

G@0, 3 $ack == l'bl; // ack should stay for 4 cycles 
60 $ce = 1'bO; 

} 

t : 
integer i ; 

for (i = 0; i < 4; i++) // drive the data for 4 consecutive cycles 
{ 

$data = data[i] async; 
e (posedge CLOCK) ; 
}//end for 

) 

join all 

01 $oe = void; // void drive to kill one more cycle 

// releasing lock 

semaphore_put ( sem_id, 1 ) ; 
}//end do_write 
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RUN 



#!/bin/csh -f 

rm -f core *.vro *.vshell >& /dev/null 
vera -cmp -g s ignal_dr ive . vr 



— 
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7. Predefined Vera Tasks 

Vera provides many predefined system tasks that are immediately available in the Vera environment 
This chapter discusses many of the system tasks and details their use. This chapter includes these sec- 
tions: 

• Vera I/O 

• Random Number Generators 

• Simulation Errors 

• Simulation Control 

• Reading Plus Arguments 

7.1 Vera I/O 

The tasks in this section are Vera's input/output tasks. 

7.1.1- Output 
printfO 

Vera supports a C-style printfO system task that sends information to stdout (verilog.log) during the 
course of a simulation. The syntax is: 

printf ( *£mt_str* , argl , arg2, .... argN) ; 
fmt__$tr - This is a C-style format string. The format specifiers that can be used arc: , *, 
%h or %H : print in hexadecimal format 
%d or %D : print in decimal format 
%o or %0 : print in octal format 
%b or %B : print in binary format 
%c or %C : print in ASCII character format 
%s or %S : print as string 
argN - These are the arguments to be printed 

For %h, %d t %o, %b, the values arc sized automatically to the maximum possible space needed for the 
given expression. You can fninimiT^ the size by inserting a zero between the % character and the letter 
that indicates the radix. For example: / v 
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printf ("Data = %0h Addr = %0h\n", data, addr); 
With %s, you can also print bind_var variables. For example: 

bind_var current; 
current = get_bind(); 

printf ("Current bind = %s\n", current); 
This example prints the bind name associated with the bind_var current. 

7.1.2 FilelO 

Vera provides predefined tasks to read and write external files. 
fopenO 

The fopenO system function opens a specified file. The syntax is: 

f open (* filename', m type" ) ; 
filename - filename specifies the file to be opened. 
type - The argument type is one of the following: 

r: open for reading 

w: truncate or create for writing 

a: append or create for writing 
The fopenO function opens the specified file and returns a 32-bit file descriptor or 0 if it fails. 

fclosef) 

The fcloseO system task closes the specified file. The syntax is: 

f close {file^descriptor); , 
file jdescrip tor - There are three predefined file descriptors in vera_defines.vrh: 

stdin: terminal input 

stdout: terminal output 

stdem terminal error output 

fprintfO 

The fprintfO system task writes the output to a specified file. The syntax is: 
s fprintf (file^descriptor, fmt_str) ; 
fmtjtr • The format string is the same as the printf 0 system task. 
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freadbO 

The freadbO system function reads binary data from a specified file and returns it as a bit vector. The 
syntax is: 

f readb ( fil e^descrip tor) ; 

The freadbO function reads binary formatted data from a specified text file, line by line, and returns the 
data as a bit vector. Lines with only white spaces and comments are ignored. Each line of the file must 
be in this format: 

white^space* binary comment* 
white _s pace - The white^space can be any number of spaces. 
binary - The binary must be a combination of *0\ M\ *z\ V, 4 Z\ 4 X* and *_* . 
comment - The comment must be a Vera comment starting with *7T . 

When the end of the file is reached, the function sets the error flag. For more information on the error 
flag, see Section 7.3, "Simulation Errors." 

freadhO 

The freadhO system function reads hexadecimal data from a specified file and returns it as a bit vector. 
The syntax is: 

freadh (file_descriptor) ; 

The freadhO function reads hex formatted data from a specified text file, line by line, and returns the 
data as a bit vector. Lines with only white spaces and comments are ignored. Each line of the file must 
be in this format: 

white_space* hex comment* 

hex -The hex must be a combination of 4 0\ 4 1\ V to T, 4 A' to 4 F, V, 4 z\ 4 X\ 4 Z* and 4 J .The 
comment must be a Vera comment starting with *7/". 

When the end of the file is reached, the function sets the error flag. For more information on the error 
flag, see Section 7.3, "Simulation Errors.*' 

freadstrO 

The freadstrO system function returns a string from a specified file. The syntax is: 
f raadatr ( file^descriptor, mode) ; 

mode - The mode can be VERBOSE, which prints a warning and returns a mull string when the end of 
the file is reached, SILENT, which returns a null string when the end of the file is reached, or 
RAWIN, which is the same as SILENT except that comments and blank lines are not filtered out 
If the mode is not specified, the default is VERBOSE. 
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The freadstr() function returns a string containing a line of text from a specified file. The returned 
string does not contain line-feed characters. Comments and blank lines in the input file are ignored by 
the function, unless the RAWIN mode is used. 

When the end of the file is reached, the function sets the error flag. For more information on the error 
flag, see Section 7.3, "Simulation Errors." 

rewindO 

The rewindO system task moves the file access pointer to the beginning of the file. The syntax is: 
rewind {file_descrip tor) ; 

File I/O Example 

This is an example that incorporates many of the predefined I/O functions: 



// Read 10 lines of 16 -bit hex data from an input file 
// and write it to another file 

bit [15:0] in_data[], out_data[]; 

string in_data_str; 

integer fdi, fdo, i; 

fdi = fopen ( • input. daf, "r" ); 
if ( fdi » o ) 

error ('Can't open input .dat! \n" ) ; 



// input method 1 - freadh 

for ( i = 0; i < 10; i++ ) 

in_data[i] = freadh ( fdi ); 
rewind ( fdi ) ; : 

// input method 2 - f reads tr 

// and output method 1 - f print f 

fdo = fopen ( "output. daf , "w" ); 
if ( fdo == 0 ) 

error ("Can't open output .dat 1 \n" ) ; 
i = 0; 

in_data_6tr = f reads tr ( fdi ) ; 
while ( in_data_str.len() > 0 ) 



tinclude <vera_def ines . vrh> 



program file_io_test 
{ 



{ 



sscanf ( in_data_str # "%h", *out_data[i] ); 
if ( out_data[i] !== in_data[ij ) 
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error ("Something's wrong\n*); 
else 

fprintf ( fdo, "Output Data : %h\n' , out_data[i] ); 
i++; 

in_data_str = f reads tr ( fdi ) ; 

} 

} 

7.2 Random Number Generators 

Vera provides pseudo-random number generators, which can be used for writing random tests and for 
randomizing test data. The random number generator is based oh the Unix random number generator, 
which uses a non-liner, additive feedback algorithm with a 256-byte state and a period of at least 

randomO 

random ( (seed] ) ; 

seed - The seed is an optional argument that determines which random number is generated. The seed 
can be any valid Vera expression, including variable expressions. The random number generator 
generates the same number every time the same seed is used. 

The random number generator is based on the Unix random number generator, which uses a non-linear 
additive feedback algorithm with a 256-byte state and a period of at least 2 35 . For more information on 
the Unix random number generator, see the Unix man pages (from a Unix shell, type "man random"). 

The random number generator is deterministic. Each time you restart your program, it cycles through 
the same random sequence. You can make this sequence indeterminate by seeding the randomO func- 
tion with an extrinsic random variable, such as the time of day. 

To generate random numbers, first call the randomO system function with a 32-bit seed value. Then 
call the randomO function without a seed each time you need a new random number. For example: 

random( 164984 ); // Initialize the generator 

addr = { random () , random ()} ; *" 
ph_number = randomO » 5; •■■.■*■-' 

urandomO 

The urandomO function generates an unsigned 32-bit random number based on the same algorithm 
used by the randomO function. The syntax is: 



urtndoat [seed] ) ; 
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rand48() 

The rand480 function generates a 32-bit non-negative random number based on the irand48() algo- 
rithm. The syntax is: 

rand* 8 ( [seed] ) ; 

For more information on the lrand48() algorithm, see the Unix man pagej (from a Unix shell, type 
"man lrand48"). 



The syntax is: 

urand48 ( [seed] ) ; 

For more information on the mrand48() algorithm, see the Unix man pager (from a Unix shell, type 
"man mrand48"). 



Vera provides a set of predefined tasks and functions that are used in handling simulation errors and in 
assisting the debugging process. 

7.3.1 Error Handling 

errorO 

The errorO system task generates a Vera simulation error. The syntax is: 

error ( • fmt_str" ) ; 
fintjtr- The fmi_str is of the same form as the printfO function. 

You can intentionally generate a a simulation error condition with the errorO system task- The system 
task prints the message specified with fint_str and then generates the error* 

For example: 

if( length > 256 ) 

error ( m Too long length %d specif ied\n* , length ); 



u rand 480 

The urand4SQ function generates an unsigned 32-bit random number based on the mrand48 algorithm. 



7.3 Simulation Errors 




flag ( t value] ) ; 



value - The value flag determines how the error flag is set The value can be ON, which sets the error 
flag, or OFF, which clears the error flag. 
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The flagO function sets and clears error flags that are raised when various non-fatal simulation errors 
occur (such as soft-expects and semaphore timeouts). The function returns the value of the flag before 
setting or clearing the flag. If no argument is passed in the call, the function only returns the state of the 
error flag. 

If the error flag is set in a child process (in a fork/join block) t the error flag is transferred to its parent 
only if the parent is waiting for the child. Returning from a task or procedure with the flag raised trig- 
gers a simulation error (default setup), and the flag is cleared. 

For example: 

foo.bus.data =?= 8'h54 soft; // soft expect 
if( flag () ) { 

printf( ^Warning: data is not 8'h54\n* ); 

flag( OFF ); 



} 



error_mode() 

The error_modeO system task sets Vera's error generation mode. The syntax is: 

error_mode ( type, error^class) ; 

type - The type must either be ON, which activates the error generation mode, or OFF, which 
deactivates the error generation mode. 

error jcloss - The error jcktss and its defaults are listed in Table 7-1. 



Table 7-1 error_class definition 


Error Class 


Definition 


Default 


EC_ARRAYX 


Error on indexing array with X value 


on 


EC.EXPECT 


Error on Expect fail ( ) 


on 


ECJFULLEXPECT 


Error on Full-Expect fail ( * 4 @@ w ) 


on 


EC.SEXPECT 


Error on Soft-Expect fail r@" soft) 


off 


EC.SFULLEXPECT 


Error on Soft-Fidl-Expect fail C 4 ^** «>&) 


off 


EC.RETURN 


Return from subroutines with error flag set, 
issues error message, and clears error flag 


on 


EC.USERSET 


flag(ON) system task is called by user 


off 


EC.SEMTMOUT 


semaphore time out error 


on 


EC.RGNTMOUT 


region timeout error 


on 


EC.MBXTMOUT 


mailbox timeout error 


on 


EC.CONFLICT 


drive conflict error 


on 


EC SCONFUCT 


Soft drive conflict error 


off 
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For example: 

error_mode ( ON, EC_USERSET ); 
error_mode( OFF, EC_RETURN ); 

7.3.2 Debug Support Routines 

traceO 

The trace() system task enables and disables trace message generation for various types of objects. The 
syntax is: 

trace {regu est, object [, id_level]) ; 

request - The request must either be ON, which activates trace message generation, or OFF, which d 
activates trace message generation. 

object - The object argument definitions are listed in Table 7-2. 



Table 7-2 Trace object definitions 



Object 


Action 


SEMAPHORE 


trace message for semaphore 


REGION 


trace message for region 


MAILBOX 


trace message for mailbox 


PROGRAM 


trace message for program 


VERBOSE 


verbose message 


<event_variable> 


trace all events on <event_variable> 



idjevel - If the object argument is an event variable or VERBOSE, the idjevel is not necessary. 

If the object argument is SEMAPHORE, REGION, or MAILBOX, the idjevel specifies the 
name of traced object 

If the object argument is PROGRAM, idjevel specifies the trace level. Level 0 only traces the 
current process. Level 1 generates traces on child processes as well. For trace levels greater than 2, 
- the trace level is set to 1 for its subroutines. For example, with trace (ON, PROGRAM, 3), the trace 
level becomes 2 at the subroutine. 

s 

Note - A new trace call overrides the given trace level. 



If the object argument is VERBOSE, the traceO function controls the generation of the verbose 
messages, including the warning messages on soft-expect fail, etc. 
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When the program trace is enabled, the Vera-VS generates a trace dump along with the internal execu- 
tion. For example: 

<TRACE> Context (0): program rrarb_test 22 in rrarb.vr 
<TRACE> Context (0): program rrarb_test 23 in rrarb.vr 
<TRACE> Context (0): program rrarb_test 24 in rrarb.vr 

The trace shows the context ID (unique ID allocated by the system), program or subroutine name, line 
number, and file name. 

Program Trace Examples 

Here are examples of program traces: 

trace ( ON, PROGRAM, 5 ); 

trace ( ON, SEMAPHORE , sem_id ); 

trace! ON, REGION, addr_begin ); 

trace ( ON, MAILBOX, ups_mbox ); 

trace ( ON, all_done_evt ); 

trace ( ON, VERBOSE ); 

trace ( OFF, PROGRAM, 1 ); 



7 A Simulation Control 

Vera provides a set of of tasks and functions used to control simulations. 
stopO 

The stopO system task stops the simulation when it is encountered. The syntax is: 
•top ( ) ; 

The stopO system task is equivalent to the Verilog task $stop. If you are running a Verilog simulation, 
the simulation stops, reports that a stop has been encountered, and exits to a Verilog prompt when the 
task is encountered. Normal Verilog commands can be issued at the command line. To continue the sim- 
ulation, enter a period (.) at the command line. 

If you are running Vera-CS standalone, the simulation stops, reports that a stop has been encountered, 
and prompts you to hit RETURN to continue. 

exitO 

The exitO system task exits the simulation when it is encountered. The syntax is: 
exit (status) ; 

status - The status must be an integer constant or integer variable. Its value is assigned to the 
environment variable Sstatus when the simulation is exited 
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The exitO exits the simulation when it is encountered. It assigns the status value to the environment 
variable Sstatus, which can be evaluated from the Unix prompt. It is particularly useful for evaluating 
flag and variable values when the simulation exits. 

get_cycle() 

The get_cycle system function returns the current simulation cycle count. The syntax is: 
get_ cycle ( ) ; 

Vera counts the internal simulation cycles at the positive edge of SystemClock. The system function 
get.cycleO returns the current simulation cycle as a 32-bit unsigned value. 

For example: 

printf( "Current Cycle: %d \n*, get_cycle() ); 

get_time() 

The get_time system function returns the current 64-bit simulation time as two 32-bit values. The syn- 
tax is: 

get_time ( word) ; 

word - The word must be either LO, which returns the lower 32-bit value, or HI, which returns the 
higher 32-bit value. 

The simulation time is evaluated from the HDL side, or from the Vera side when running Vera-CS stan- 
dalone. 

For example: 

printf( "Current Time: %d.%d \n* ( get_time (HI) , get_time (LO) ); 

get_systime() 

The get_systimeO system function returns the number of seconds since 00:00: UTC, January 1, 1970. 
The syntax is: 

get_»y« time ( ) / 

The get_systime0 system function corresponds to the Unix library function timeO (see the Unix man 
pages for more information). 

7,5 Reading Plus Arguments 

Vera can read Verilog plus arguments using the get jlus.argO system function. The VHDL equivalent 
to plus arguments is included in the vcra.ini file, discussed in Section 173.2, "VHDL Plus Arguments.* 1 
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get„plus_arg() 

Within a Vera program you can check any plus arguments on the Verilog command line by using the 
get_plus_arg0 system task. 

ge t_plus_arff ( regues t . pi us_arg) ; 
request - The valid values for request are listed in Table 7-3. 



Table 7-3 


Plus Argument Requests 


Request 


Action 


CHECK 


returns 1 if the specified plus argument is 




present 


HNUM 


returns a hexadecimal number attached to the 




specified plus argument 


NUM 


returns an integer attached to the specified 




plus argument 


STR 


returns a string attached to the specified plus 




argument (returns a bit string type and not a 




string primitive type) 



plusjtrg - The plusjarg is the plus argument you want to evaluate. 

The get _plus_argO system function returns a value based on the request type and plus_arg value. 

For example: 

# include <vera_def ines . vrh> 
#define DEF_RP_TIMES 10 
idefine DEF_RSEED 32 *habcd_ef 01 
#define DEF_LOG_FILE_NAME "test. log- 
program test 
{ 

integer repeat^ times = DEF_RP_TIMES; 
bit [31:0] random_seed «= DEF_RSEED; 
bit [2047:0] bit_str; //max 256 char 
string log_f ile_name = DEF_LOG_FILE_NAME ; 

// get repeat times if any 

if ( get_plus_arg ( CHECK. •set_repeat_times=' ) ) 
{ 

repeat_times = get_plus_arg ( NUM. ■set_repeat_times=" ) ; 

} 

// get random seed if any 
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if ( get_plus_arg ( CHECK, •set_random_seed= " ) ) 
{ 

random_seed = get_plus_arg ( HNUM, •set_random_seed=* ); 

} 

// get log file name if any 

if ( get_plus_arg ( CHECK, "set_log_f ile__name=' ) ) 



bit_ctr = get_plus_arg ( STR, 'set_log_f ile_name=" ) ; 
log_file_name.bittostr ( bit_str ); 

} 

printf (" repeat times is %0d\n", repeat^ times ); 
printf (" random seed is %h\n*, random_seed ); 
printf (• log file name is %s\n", log_f ile_name ); 



This example is invoked with this command line: 

vera.cs filename. vro +set_repeat_times=7 +set_log_file_name=log.f ile \ 
+ s e t_ random_s eed=3 



{ 



) 
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8. Object-Oriented Programing 

Object-oriented programming is at the very core of Vera. The implementation is dear, straight- 
forward and elegant, assimilating and extending the best of the features found in C++ and Ja- 
va. For the new user, this implementation will prove easy to learn and powerful to use. The 
advanced user will find the Vera implementation to be intellectually deep and compelling. 

Most of the features of Vera are available without using the object-oriented framework. You 
can be a good Vera programmer without ever defining a class, instantiating an object, or in- 
voking a method. The basic object-oriented capabilities, however, are straightforward and easy 
to learn, and the consequent improvements in your productivity will be immense. 

By using the object-oriented paradigm, your program will be easier to design, easier to devel- 
op, easier to debug, easier to maintain, easier to share, and easier to re-use. This all follows 
from the fundamental orientation of the paradigm, which leads you to group related data and 
code into separable and separated units called classes. A class might be as low-level as a pack- 
et or as high-level as a complete processor description. Each instance of a class, called an ob- 
ject, has its own copy of its data as well as access to the code that acts on this data. Classes 
have both public and private data and code. Private data and code inside the class is inviolate 
- outside programs cannot access it, except indirectly through public access methods. Almost 
as importantly, code inside the class can't have any unforeseen side-effects outside of the class. 
The focus of all code actions is strictly inside the class. 

Object-oriented programming leads naturally to grouping related code arid data together, 
keeping these sections small, easy to understand, easy to debug and easy to maintain. It also 
leads to crisply formalizing the interactions among these classes. The result is a discipline and 
program structure that is useful for small programs, but has a dramatic, powerful impact on 
your productivity as soon as your program becomes large or in any way complex. -; 

Object-oriented programming, especially with a dean implementation such as is found here, is 
more a matter of perspective and mindset than of features and syntax. The paradigm is built 
on three tenets: encapsulation, inheritance and polymorphism. 

Encapsulation is the concept of bringing related code and data together and making access 
into or out of the class formal and rigorous, hiding almost all of the detail in the class from the 
outside world. 

Inheritance is the idea that once a class is debugged, you don't want to modify it for a new ap- 
plication or use. You would rather inherit features you can use and replace features you need 
to change. This leads to die notion of a base class with general, widely applicable core features 
and a cte s< hierarchy of subclasses, where each member of the hierarchy inherits core features 
from its parent, adds new features that make the subclass more specific and refined, and then 
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passes this more complete set on to its descendants. An example might be a base class that de- 
fines vehicles - providing the basic properties that are generic to all vehicles. We could then 
extend these properties to include the properties specific to land vehicles. This could be fur- 
ther extended to give us wheeled vehicles, then cars, then Toyotas and ultimately the Toyota 
Tercel - an actual example of a vehicle, a land-vehicle, a wheeled vehicle, etc. Later, we could 
derive a new class for air-vehicles, motorcycles or Ferraris - all by extending the appropriate 
subclass. If we planned carefully we would not have to redo a lot of work, and the extensions 
would be straightforward. 

The third tenet of the object-oriented paradigm is polymorphism. This allows us to wait until 
run time to bind object variables to their data type. Traditional languages with simple data 
types don't allow you to do this; an integer is different from a string, and the two could never 
occupy the same variable. But with object-oriented programming, the range of data types are 
unlimited, and this traditional restriction often is a hindrance. For example, we might have a 
variable called coordinate where we have different versions (classes) defining a coordinate: 
cartesian, polar, spherical, cylindrical, in two or three dimensions. The subroutines would 
have the same names in all of the class declarations; all might have a subroutine that could 
compute the distance between two points or the distance from the origin to a point, dis- 
tance ( coordinate c ) . With polymorphism, when you call the subroutine distance ( ) at 
run time, the system looks at the type of the data (of coordinate) and decides which version 
of distance to invoke. 

8.1 Classes and Objects 

A class is a collection of data and a set of subroutines that operate on that data. A class's data 
is referred to as properties, subroutines are called methods, and we will refer to both as members 
of the class. The properties and methods, taken together, usually define the contents and capa- 
bilities of some kind of object. 

For example, a packet is an object It might have a command field, an address, a sequence 
number, a time stamp, and a packet payload. In addition, there are various things we can do 
with a packet initializing the packet, setting the command, reading the packet's status, check- 
ing the sequence number: Each Packet is different, but as a class, packets have certain intrin- 
sic properties that we can capture in a definition. 

Example: 

class Packet { 

bit [3:0) command; // data portion 

bit [40:0] address ; 
bit [4:0] master_id; 
■integer time_requested; 
{ local integer time_issued; 

local integer status; 

. task new () { // initialization 

command = IDLE; ? 1 

Synopsy^inc. 
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address = 41 'b0; 
master_id = 5'bx; 

} 

/* private operations, internal to the class */ 
local task clean () { 

command = 0; address =0; master_id = 5'bx; 

) 

/* public access entry points */ 
task issue_request ( integer delay ) { 
// send request to bus 
// ... 

} 

function integer current_status ( ) { 
current_status = status; 

} 

) 

Note that a common convention is to capitalize the first letter of the class name, so that it is 
easy to recognize class declarations. 

8.2 Objects and Instance of Classes 

So far, we only have the definition of the class Packet. We have created a new, complex data 
type but we can't do anything with the class itself. We need to create an instance of the class, a 
single Packet object The first step is to create a variable that can hold an object's name (or 
handle): 

Packet p; 

Nothing has been created yet We have just declared that p is a variable that can hold the han- 
dle of a Packet object. In Vera, for p to refer to something, we need to explicitly create an in- 
stance of the class using the new keyword. ■ 

Packet p; 
p = new; 

You can detect uninitialized object handles by comparing them with null. For example: 

class obj_foo 
{ 

) 

task xnytask (integer a. <obj_foo myfoo = null)) 
{ 

if (myfoo == null) myfoo = new; 

) 

This example checks if myfoo is initialized. If it is not, it initializes it with the new command. 
Synopsys Inc. . 
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8.3 Accessing Object Properties 

Now that we have created an object, we can use its data fields by qualifying property names 
with an instance name. Looking at the earlier example, we can use the commands for our 
Packet p as follows: 

Packet p = new; 

p. command = INIT; 

p. address = random(); 

time = p. time_requested; 

8.4 Using Object Methods 

To access an object's methods, we use the same syntax we used to access properties: 

Packet p = new; 

status = p . current_status ( ) ; 

Note that we did not say 

status = current_status (p) ; 

The focus in object-oriented programming is the object, in this case the packet, not the func- 
tion call Also, objects are self-contained, with their own methods for manipulating their own 
properties. So we don't have to pass arguments to get_status ( ) . The properties of a class 
are freely and broadly available to the methods of the class, but each method only accesses the 
properties associated with its object, its instance. 

8.5 Constructors 

Vera does not require the complex memory allocation and de-allocation of C++. Construction 
of an object is straightforward and garbage collection, as in Java, is implicit and automatic. 
There can be no memory leaks or other subtle behavior that is so often the bane of C++ pro- 
grammers. 

Vera provides a mechanism for initializing an instance at the time the object is created. When 
you create an object, for example 

Packet p = new; 
the system executes the new task associated with the class: 

class Packet { 

integer command; 

task new () { command = IDLE; } - 
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Note that new is now being used in two very different contexts with very different semantics. 
The variable declaration creates an object of class Packet. In the course of creating this in- 
stance, the new subroutine is invoked, if it exists, allowing you to do any initialization or start- 
up functions you require. The new task is also called the constructor of a class. 

It is also possible to pass arguments to the constructor, to allow for run-time customization of 
the object 

Packet p = new ( STARTUP , randomO, get_time (LO) ) ; 
where the new initialization task in Packet might now look like 

task new (integer in_coxnmand=IDLE, bit[40:0] in_address=0, 
integer time_stamp=0) { 
command = in_command; address = in_address; 
time_requested = time_ stamp; 

} ' 

The conventions for arguments are the same as for subroutine calls, including the use of de- 
fault arguments. 

8.6 Class Properties 

So far, we have only declared instance properties. Each instance of the class, each Packet, has 
its own copy of each of its three variables. There are also cases where we only want one copy 
of the variable, to be shared by all instances. These class properties are created using the stat- 
ic keyword. Thus, for example, in a case where all instances of a class need access to a sema- 
phore id, we might have 

class Packet { 

static integer semld = alloc (SEMAPHORE, 0, 1, 1) ; 

Now, semld will be created and initialized the first time an object of the Packet class is cre- 
ated. Thereafter, every packet object can access the semaphore in the usual way: 

Packet p; .... .i. . .■ 

semaphore_get (WAIT, p. semld); 

8.7 this 

There are times when you need to unambiguously refer to properties or methods in the cur- 
rent instance. For example, the following declaration is a common, clean way to write an ini- 
realization routine; 
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class Demo { 
integer x; 

task new (integer x) { 
this.x = x; 
) 

x is now both a property of the class and an argument to the task new. In the task new, an un- 
qualified reference to x will be resolved by looking at the innermost scope, in this case the 
subroutine argument declaration. To access the instance property, we qualify it with 'this' to 
refer to the current instance. 

Note that in writing methods, you can always qualify members with this to refer to the cur- 
rent instance, but it is usually unnecessary. 

8.8 Assignment, Re-naming and Copying 

When we declare a class variable, we have only created a name for an object. Thus 
Packet pi; 

creates a variable, pi, that can hold the handle of an object of class Packet, but the initial value 
of pi is null It is not until we create an instance of type Packet that the object exists, and . 
that pi contains an actual handle: 

pi = new; 
Thus, if we create another variable 

Packet p2; 
and assign pi to p2 

p2 = pi; 

then we still have only one object, which we can refer to with either the name pi or p2. Note, 
we have only executed new once, so we have only created one object 

If we rewrite the last expression slightly differently, however, we make a copy of pi: 

p2 = new pi; 

Now we have executed new twice, so we have created two objects. With this syntax, however, 
p2 will be a copy of pi, but it will be what is known as a shallow copy. All of the variables are 
copied across: integers, strings, instance handles, etc Objects, however, are not copied, only 
their handles; as before, we have created two names for the same object This is true even if 
the class declaration includes the instantiation operator new: 
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class A {integer j = 5; } 
class B { 

integer i = 1; 

A a = new; 

} 

program test { 
integer test; 

B bl = new; // Create an object of class B 

B b2 = new bl; // Create an object that is a copy of bl 

b2.i = 10; // i is changed in b2, but not in bl 

b2.a.j = 50; // change object a, shared by both bl and b2 - 

test = bl.i; // test will be set to 1 (bl.i has not changed) 

test = bl.a.j; // test will be set to 50 (a.j has changed) 

Note several things. We can initialize properties and instantiate objects directly in a class dec- 
laration. Second, the shallow copy does not copy objects. Third, we can chain instance qualifi- 
cations as needed to reach into objects or to reach through objects: 

bl.a.j // reaches into a, which is a property of bl 

p.next.next.next.next.val // would chain through a sequence of 

// handles to get to val. 

To do a full (deep) copy, where everything (including nested objects) are copied, you need to 
write custom code. Thus, we might have 



Packet pi = new; 
Packet p2 = new; 
~ J p2. copy (pi); 

where copy (Packet p) is a method written to copy the object specified as its argument into 
its instance. 

8.9 Subclasses and Inheritance 

We have defined a class that declares a Packet. Now, assume we want to extend this declara- 
tion so that, for example, we could chain packets together on a list We could create a new 
class which has, as a property, a variable of type Packet. We would be nesting classes, like a 
set of Russian dolls; the references, as we saw in the previous example, can quickly become 
cumbersome. 

A much preferred alternative is to extend the class, creating a new subclass that inherits the 
members of the parent class. Thus, for example, we could have 
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class LinkedPacket extends Packet { 
LinkedPacket next; 

function LinkedPacket get_next() { get_next = next; } 
} 

Now, all of the methods and properties of Packet are part of LinkedPacket - as if they were 
defined in LinkedPacket - and LinkedPacket has additional properties and methods. 

We can also override the parent's methods, changing their definitions. 



8.10 Overridden Members 

Subclasses objects are also legal representative objects of their parent classes. For example, ev- 
ery LinkedPacket object is a perfectly legal Packet object; we can assign the handle of a 
LinkedPacket object to a Packet variable: 

LinkedPacket = new; 
Packet p = lp; 

In this case, references to p access the methods and properties of the Packet class. So, for ex- 
ample, if you have overridden properties and methods in LinkedPacket, when you refer- 
ence these overridden members through p you get the original members in the Packet class. 
From p, new and overridden members in LinkedPacket are hidden from you. 

class Packet { 

integer i = 1; 

function integer get() { get = i; } 
} 

class LinkedPacket extends Packet { 
integer i = 2; 

function integer get() { get = -i; } 
) 

LinkedPacket lp = new; 
Packet p = lp; 

j = p-i; 
j = p.getO ; 

Note that this is different from the semantics of, for example, Java. In Java, you would get the 
original properties, but you would get the overridden methods of the child class. In Vera, to 
get the overridden method, the parent method needs to be declared virtual (see below). 



// j = 1. not 2 

// j = 1, not -1 or -2 
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8.11 superclass 

Every subclass has a super class, its parent class referred to in the extends clause of the class 
declaration. When members have been overridden in the subclass, you can access the super- 
class versions from methods in the subclass by qualifying the member name with the keyword 
super: 

super . count; 

super.clear_table() ; 

This only allows you to reach up one level of the hierarchy; this may be a member declared a 
level up or a member inherited by the class one level up. There is no way to reach higher (su- 
per . super . count is not allowed). 

(In the sequel when we refer to subclasses, we will be referring to classes that are extensions 
of the current class. When we refer to super-classes, these will be the classes that the current 
class is extended from, beginning with the original base class.) 

8.12 Casting 

It is always legal to assign subclass variable to a variable of superclass higher in the inherit- 
ance tree. It is never legal to directly assign a superclass variable to a variable of one of its sub- 
classes. However, it may be legal to place the contents of the superclass handle in a subclass 
variable. 

• To check if the assignment will be legal, use the function cast_assign ( ) : 

function integer cast_assign(var destination_handle, source_handle) ; 

This function checks that the contents of source_handle is of class destination_handle or 
one of its subclasses. If it is, cast_assign does the assignment; if it is not, cast_assign ( ) 
generates an error and terminates. 

A second version of this function allows you to check the results without generating an error 
cast_assign(destination_handle, source_handle, CHECK); 

does the assignment and returns. a 1 if the assignment is valid. Otherwise/it sets the destina- 
tion handle to null and returns a 0. 



8,13 Chaining Constructors 

When you instantiate a subclass, one of the system's first actions is to invoke the class method 
new ( ) • The first, implicit action new ( ) takes is to invoke the new ( ) method of its superclass, 
and so on up the inheritance hierarchy. Thus, all of the constructors get called, in the proper 
order, beginning with the base class and ending with the current class. 

— 
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If the initialization method of the super-class requires arguments, you have two choices. If you 
want to always supply the same arguments, you can specify them at the time you extend the 
class: 

class EtherPacket extends Packet (5) { 

This will pass 5 to the new routine associated with Packet. A more general approach is to use 
the super keyword, to call the superclass constructor as the first executable statement of the con- 
structor: 

task newO { 

super. new (5) ; 

8.1 4 Data Hiding and Encapsulation 

So far, we have made all of our properties and methods available to the outside world without 
restriction. However, for most data (and most subroutines) we want to hide them away from 
the outside world, "seal them away in the capsule*' of the class. This keeps other programmers 
from relying on your specific implementation - so you can safely modify it later - and it also 
protects against accidental modifications to properties that are internal to the class. When all. 
data becomes hidden - being accessed only by public methods - testing and maintenance of 
the code becomes much easier. 

Unlabeled properties and methods are public, available to anyone who has access to the ob- 
ject's name. 

A member identified as local is available only to methods inside the class. Further, these lo- 
cal members are not visible even to subclasses and cannot be inherited. Of course, non-local 
methods that access local properties or methods can be inherited, and work properly as 
methods of the subclass. 

A protected property or method has all of the characteristics of a local member, except 
that it can be inherited; it is visible to subclasses. 

Note that within the class, we can reference a local method or property of our class, even if 
it is in a different instance. For example 

class Packet { 

local integer i; 

function integer compare (Packet other) { 
compare = (this . i == other. i); 

) '* -< • ' 

A strict interpretation of encapsulation might say that other . i should not visible inside of 
this packet, since it is a local property being referenced from outside its instance. Within 
the same class, however, these references are allowed. In this case, this . i will be compared 
to other . i and the result of the logical comparison will be returned. 
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In summary 

• wherever possible, use local members. Hide members that the outside 
world doesn't need to know about; 

• use protected members if the outside world doesn't have a need to know, 
but subclasses might; 

• public access should only be allowed when it is absolutely necessary, and the 
access should be limited as much as possible. Generally, don't provide direct 
access to properties but rather provide access methods - provide, for 
example, only read access if a variable should never be written. This 
provides an extra level of protection and preserves flexibuity for future 
changes. 



8.15 Philosophy 

Notice that there has been a subtle yet profound shift in the way we are working with vari- 
ables. In a traditional programming language variables are either global, with too broad a 
scope, or local with too narrow a scope. Global variables often get woven through the fabric 
of the program, with no way, in large programs especially, to understand the ramifications of 
making changes, or to keep programmers from relying on the implications and side effects of 
the specific implementation. Local variables have the opposite problem. They are so restricted 
in scope that you are always having to pass them explicitly, cluttering the code with redun- 
dant declarations and intermediate variables. 

In the object-oriented paradigm, we have created two intermediate classes of variables - much 
more visible than the old local variables yet much less visible than global variables. Variables 
which are declared local in the object-oriented paradigm are generally available, but only 
within a very carefully circumscribed context - only to the methods of the variable's immedi- 
ate object. If your classes are weU drawn, this is exactly the code that you want to have access 
to this type of variable. o ; 

This scope can also be broadened a bit more, by declaring the variable static. Now the vari- 
able becomes available to every object in the class, but it is still not available to the toajoriry of 
the code, the code mat lies outside me class. 

In object-oriented programming, the language has become much more careful with the way 
variables are handled, while at the same time becoming more terse, more expressive' and easi- 
er to' read and understand. 

8.1 6 Abstract Classes and Virtual Methods 

Often we create a set of classes that can be viewed as all derived from a common base class. 
For example, we might start with a common base class of type BasePacket that sets out the 
structure of packets but is incomplete; we would never want to instantiate it From this base 
class, though, we might derive a number of useful subclasses: Ethernet packets, token ring 
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packets, GPSS packets, satellite packets. Each of these packets might look very similar, all 
needing the same set of methods, but they could vary significantly in terms of their internal 
details. 

We start by creating the base class that sets out the prototype for these subclasses. Since we 
don't need to instantiate the base class, we declare it to be abstract by declaring the class to be 
virtual; 

virtual class BasePacket { 

By themselves, abstract classes are not tremendously interesting, but abstract classes can also 
have virtual methods. Virtual methods provide prototypes for subroutines, all of the informa- 
tion generally found on the first line of a method declaration; the encapsulation criteria, the 
type and number of arguments, and the return type if it is needed. Later, when subclasses 
override virtual methods, they must follow the prototype exactly. Thus, all versions of the vir- 
tual method will look identical in all subclasses: 

virtual class BasePacket { 

virtual protected function integer send (bit [31 : 0] data); 
) 

class EtherPacket extends BasePacket { 

protected function integer send (bit [31 : 0] data) { 
// body of the function 

} 

EtherPacket is now a class we can instantiate. In general, if an abstract class has several vir- 
tual methods, all of the methods must be overridden for the subclass to be instantiable. If all 
of the methods are not overridden, the subclass needs to be abstract. 

Methods of normal classes can also be declared virtual. In this case, the method must have a 
:; . body. If the method does have a body, then the class can be instantiated, as can its subclasses. 
However; if the subclass overrides the virtual method, men the new method must exactly 
match the superclass's prototype. 

8.17 Finding the Right Method 

There are several subtleties that arise when we start using virtual methods, although the un- 
derlying rules are quite simple. At some point, the compiler or the run-time system needs to 
find the proper method. If we have a simple case, with no inheritance, then the answer is ob- 
vious. 

-GigaEther Packet p = new; 
.p.sendO ; . 
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We will invoke the send ( ) method declared in GigaEtherPacket. But if we have inherited 
a virtual method, we need to find the right version. If GigaEtherPacket is a subclass, and 
doesn't declare send ( ) , where do we go? 

The first step is to decide where in the class hierarchy to begin searching for the method. The 
rule is simple: we begin searching from the class associated with the handle for the method we 
need to find: 

• in the case above, this would be the class GigaEtherPacket. 

• if the method is being invoked from inside another method, then the handle 
is the invoking method's class; if send ( ) now invokes setup ( ) , we would 
start with the class containing send ( ) : 

task sendO { 
setup () ; 

the handle for this reference to setupO is, of course, the implicit handle "this": 

task sendO { 
this . setup ( ) ; 

The second step is to search the hierarchy: 

<- if the method is not defined at this level, begin going up the inheritance tree, 
unless 

• the method is defined in the superclass as local, then the inheritance 
chain is broken (you can't inherit this method) and we have an error, or 

• we are at the base class, in which case the method was not found 

• if the method is defined but is not virtual, use it. 

• otherwise, it must be virtual. Search from this class down the inheritance 
tree. 

• if you find a non-virtual method, use it 

• if you hit the bottom of the tree, use the most recent virtual method with 
a body; this will be the method closest to the bottom of the tree. If there 
is none, the search failed. -J: .n-, 

This search criteria is straightforward. Go up the inheritance tree until you find a method you 
can use. If it is virtual, go back down the tree until you find a non-virtual method, If you hit 
bottom without finding one, then use the last virtual method with a body you came across 

For example, if we have 

class BasePacket { 

virtual task send (integer value); 

task initO { send(0); )// calls a virtual task • 

) ' ■. . . . : . 

class EtherPacket extends BasePacket ( 

{ 

//no re-declaration of sendO or initO 
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} 

class EtherlOO extends EtherPacket { 
{ 

task send (integer value) { ... } 
} 

Etherl 0 0 ep = new ; 

Now, if we invoke ep . ini t ( ) , the system will execute the version of init ( ) defined in 
BasePacket, but the version of send { ) declared in EtherlOO . 

Note: If a method is declared virtual in a base class, it is usually a good idea to declare it vir- 
tual in the subclasses, too. 

8.18 Polymorphism: Dynamic Method Lookup 

Polymorphism allows us to use superclass variables to hold subclass objects, and to reference 
the methods of those subclasses directly from the superclass variable. As an example, consider 
the base class for our packet objects, BasePacket, Assume that it defines, as virtual func- 
tions, all of the public methods that are to be generally used by its subclasses, methods such as 
send, receive, print, etc Even though BasePacket is abstract, we can still use it to de- 
clare a variable: 

BasePacket packets [100]; 

We can now create instances of various packet objects, and we can put these into the array we 
just created: 

EtherPacket ep = new; 
TokenPacket tp = new; 
GPSSPacket gp = new; 

packets (0] = ep; packets [1] = tp; packets [2] = t gp; 

If our data types were, for example, integers, bits and strings, we couldn't store all of these 
types into a single array, but with polymorphism we can with objects. In this example, since the 
methods were declared as virtual, we can access the appropriate subclass methods from the 
superclass variable even though the compiler didn't know - at compile time, - what was going 
to be loaded into, for example, packets [ 1 ] . 

packets { 1 ] . send ( ) ; 

will invoke the send method associated with the TokenPacket class. At run-time, the system 
correctly binds the method from the appropriate class. 

This is a typical example of polymorphism at work, providing capabilities that are far more 
powerful than what is found in a non-object-oriented language. 
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8.1 9 Out of Block Declarations 

It is generally good coding practice to keep the class declaration to about a page. This makes 
the class easy to understand and to remember; declarations that go on for pages are hard to 
follow, and it is easy to miss short methods buried among the multi-page declarations. 

To make this practical, it is best to move long method definitions out of the body of the class 
declaration. You do this in two steps. Within the class body, you declare the method prototype 
. whether it is a function or task, any attributes (local, protected, public, and/or virtual), and 
the full specification of its arguments. Then, outside of the class, you declare the full method - 
including the prototype but without the attributes - and, to tie the method back to its class, 
you qualify the method name with the class name and a pair of colons: 

class Packet 
{ 

Packet next ; 

function Packet get_next() { get_next = next; }// single line 
protected virtual function integer send (integer value); 

} 

function integer Packet :: send (integer value) 
{ // dropped protected virtual, added Packet:: 
// body of method 

} 

The first lines of each part of the method declaration are nearly identical, except for the at- 
tributes and class-reference fields. 

8.20 External Classes 

As with subroutines, the class declaration can be in a separate file from the code that instanti- 
ates and invokes the class; you need to provide an external declaration of the class to support 
the tight type-checking required by Vera. The attributes and the method prototypes need to be 
re-declared: 

extern class packet { 

bit 13:0] command; 

bit 140:0] address; 

bit [4:0] master_id; 

task issue_request( integer delay ); 

function integer current_status ( ) ; 

) 

Only the local and public members of the class must be listed in the extern class declaration. 
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Note - The -h flag will cause the Vera compiler to automatically 
generate the extern class declarations for you, in a .vrh file. 



8.21 Typedef 

Sometimes you need to declare a class variable before the class itself has been declared. For ex- 
ample, two classes may each need a handle to the other. When, in the course of processing the 
declaration for the first class, the compiler encounters the reference to the second class, that 
reference is undefined and the compiler flags it as an error. The way around this is to use 
typedef to provide an interim declaration for the second class: 

typedef class C2; // C2 is declared to be of type class 

class CI { 

C2 c; 

} 

class C2 { 
CI c; 
} 

So, C2 is of type class, a fact that is re-enforced later in the source code. 
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Example 3: Object-Oriented Programming 

This is an example of the arbiter in Example 2 using the object-oriented methodology. The ex- 
ample includes these features: 

• Classes and objects 

• Class properties 

• Subclasses and Inheritance 

• External classes 

This example includes these files: 

• arb.if.vr 

• main.vr 

• cla$$es.vr 

• drivejasks.vr • . 

• RUN (a run script) 

The RUN script generates header files for classes.vr and drivejasks.vr. 

arb.if.vrh 

tdefine 0UTPUT_SKEW #1 

# define INPUT_EDGE PS AMPLE 

interface arb 
( 

output [31:0] menuaddr PH0LD OUTPUT_SKEW; 

inout (15:0] mem^data INPUT_EDGE PRZ OUTPUT_SKEW vca rz;// vca monitor 

output oe PHOLD OUTPUT_SKEW; 

output ce PHOLD OOTPUT_SKEW; 

input ack INPUT_EDGE vca rO; // vca monitor 

input elk CLOCK; 

) 

port gene ri export 
{ 

addr; 
data; 
oe; 
ce; 
ack; 

} 
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bind generic_port port_a 
{ 

addr arb.mem_addr; 
data arb.mem_data; 
oe arb.oe; 
ce arb.ce; 
ack arb.ack; 

} 

bind generic_port port_b 
{ 

addr arb . meir\_addr ; 
data arb.mem_data; 
oe arb . oe ; 
ce arb . ce ; 
ack arb.ack; 

} 



main.vr 

# include <vera_def ines . vrh> 
# include *arb.if.vrh - 
#include "classes .vrh' 

program classes_test 
{ 

integer sem_id; 
B_RD_Packet_Type rd_pack [ ] ; 
B_WH_Packet_Type wr_pack [ ] ; 

// allocate one semaphore for exclusive access to memory 

sem_id = alloc ( SEMAPHORE, 0, 1, 1 ); 
fork 
{ 

// port_a stuff 
integer i; 

// generate 10 wr-packets to write to 10 locations 

for ( i = 0; i < 10; i++ ) 
{ 

wr_pack ( i ] = new; 

do_whatever with port_a ( wr_pack(i] ); 

} 

// generate 10 rd-packets to read from 10 locations 
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. for ( i = 0; i < 10; i++ ) 
{ 

rd_pack[i] = new; 

rd_pack[i] .addr = wr_pack[i] .addr; 
do_whatever with port_a ( rd_pack[i] ); 

} 

) 
{ 

// portjb stuff 
integer i; 

// generate 10 wr-packets to write to 10 locations 

for ( i = 10; i < 20; i++ ) 
{ 

wr_pack[i] = new; 

do_whatever with port_b ( wr_pack(i] ); 

) 

// generate 10 rd-packets to read from 10 locations 

for ( i = 10; i < 20; i++ ) 
{ 

rd_pack[i] = new; 

rd_pack [ i 3 . addr = wr_pack [ i ] . addr ; 
do_whatever with port_b ( rd_pack[i] ); 

} 

} 

join all 

printf C\n\n All Finished \n m ) ; 

}//end program 

task do_whatever with generic_port ( Action_Packet_Type apt ) 
{ 

// these virtual methods call mechanism will propagate down 
// and find the right version for the derived obj 

apt. act ion with ( getJbindO ) (); 
apt .print_members ( ) ; 
}//end task do_whatever 

classes.vr 

# inc lude < vera_de f ines . vrh> 
♦include -arb.if.vrh- 

# include • dr i ve_tasks . vrh • 

• • " *v>- > ■ .** 
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extern integer randseed; 

// Virtual base class with 2 virtual function 

// for inherited classes to customize on their own. 

virtual class Action_Packet_Type 
{ 

virtual task print_members ( ) ; 

virtual task action with generic_port { ) ; 

} 

// Derived class for action type of burst- read 

class B_RD_Packet_Type extends Action_Packet_Type 
{ 

static integer inst_num = 0; 
integer inst_id; 
bit [15:0] data [4] ; 
bit [31:0] addr; 

task new <) 
{ 

addr = random ( randseed ) & 8'hfc; // 4 -bytes aligned 
inst_id = inst_num++; 

printf (*B_RD_Packet_Type inst %0d is created\n", inst_id ) ; 

} 

task print_members () 
{ 

integer i; 

printf CB_RD_Packet_Type inst %0d has the following members :\n # , 

inst_id ) ; 
printf (• addr : %h\n', addr ); 

for ( i = 0; i < 4; i++ ) 

printf (• data(%0d] : %h\n-, i, data(i] ); 

printf C\n\n-) ; 

) 

task action with generic_port () 
{ 

printf CB_RD_Packet_Type inst %0d will do a burst read\n' , inst_id) ; 
do_read with (get_bind()) ( addr, data ); 

) 

}//end B_RD_Packet_Type defn 



// Derived class for action type of burst-write 
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class B_WR_Packet_Type extends Action_Packet_Type 
{ 

\ static integer inst_num =0; 

integer ,inst_id; 
bit [15:0] data 14]; 
bit [31:0] addr; 

task new () 
{ 

integer i ; 

addr = random ( rands eed ) & 8'hfc; // 4 -bytes aligned 
for ( i = 0; i < 4; i++ ) 

data[i] = random ( rands eed ); 
inst — id = inst_num++; 

printf ("B_RD_Packet_Type inst %0d is created\n*, inst_id ); 

} 

task print_members () 
{ 

integer i ; 

printf CB_RD_Packet_Type inst %0d has the following members :\n", 

inst_id ) ; 
printf C addr : %h\n* , addr ); 

for ( i = 0; i < 4; i++ ) 

printf <■ data[%0d] : %h\n', i, data [i J ); 

printf C\n\n'); 

} 

task action with generic_port () 
{ 

printf CB.WR^PacketJType inst %0d will do a burst write \n ■ , 
inst_id) ; 

do_write with (get_bind()) ( addr, data ); 

) ' ' * — 

)//end class B_WH_Packet_Type defn 

drive_tasks.vr 

# include <yera_def ines . vrh> 
ft include "arb.if.vrh" 

extern integer sem_id; 

// do.read : acquire semaphore and do burst read at the addr 
// release semaphore by the end 
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task do_read with generic_port ( bit (31:0] addr, var bit [15:0] data [4] ) 
{ 

// acquiring lock on to driving /sampling signals 

semaphore_get ( WAIT, sem_id, 1 ) ; 

61 $addr <= addr; .//. drive the addr, oe, ce bits 

$oe = l'bl; 

$ce = l'bl; 

62, 10 $ack == l'bl; // ack should have come within 8 cycles 

fork 

{ 

660, 3 $ack == l'bl; // ack should stay for 4 cycles 
60 $oe <= l'bO; // at the end, deassert oe and ce 
GO $ce = l'bO; 

} 
{ 

integer i ; 

for (i = 0; i < 4; i++) // latch the data for 4 consecutive cycles 
{ 

6(posedge CLOCK) ; 
data[i] = $data; 
}//end for 

} 

join all 

61 $oe = void; // void drive to kill one more cycle 

// releasing lock 

semaphore_put ( sem_id, 1 ) ; 
} / / end do_r ead 

// do_write : acquire semaphore and do burst write at the addr 
// release the semaphore by the end 

task do_write with generic_port ( bit (31:0] addr, bit (15:0] data (4] ) 

// acquiring lock on to driving /sampling signals 
semaphore_get ( WAIT, sem_id, 1 ) ; 
80 $addr <= addr; // drive the addr, oe, ce bits 
$oe = l'bO; 
$ce = l'bl; 

62, 10 Sack == l'bl; // ack should have come within 8 cycles 

fork 

{ 

600, 3 $ack == l'bl; // ack should stay for 4 cycles 
GO $ce = l'bO; 

) 



m 



m 

- ; 
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{ 

integer i ; 

for (i = 0; i < 4; // drive the data for 4 consecutive cycles 

{ 

$data = data[i] async; 
@ (posedge CLOCK) ; 
}//end for 

} 

join all 

€1 $oe = void; // void drive to kill one more cycle 

// releasing lock 

semaphore_put ( sem_id, 1 ) ; 3 
}//end do_write 



RUN 



#!/bin/csh -f 

rm -f core *.vshell *.yro >! /dev/null 

vera -cmp -g -h drive_tasks . vr 

if ($status) exit 1 

vera -cmp -g -h classes. vr 

if ($status) exit 1 

vera -cmp -g main. vr 

if ($status) exit 1 
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9. Automated Stimulus Generation 

This chapter details Vera's automated stimulus generation. It focuses on constraint-driven stimulus gen- 
eration and data packing. This chapter contains these sections: 

• Introduction to Stimulus Generation 

• Stimulus Generation Overview 

• Random Packet Generation 

• Data Packing and Unpacking 

9.1 Introduction to Stimulus Generation 

Efforts to manually generate tests sufficient for verifying modern circuit designs have been rendered al- 
most completely ineffective. The sheer complexity of designs, involving hundreds of valid states and 
transitions, makes deterministic tests inconceivable. The burden of generating stimuli to drive simula- 
tions must fall squarely on the verification tool. 

The solution resides not in data sets that drive simulation testbenches but in random stimuli that ensure 
complete coverage of the hardware design. However, even this answer is not sufficient to efficiently 
and completely test a design. The ability to narrow the scope of the random stimuli such that test cases 
are not repeated and unnecessary tests are not performed can significantly speed up the verification pro- 
cess. 

To meet this end, Vera makes use of constraint-driven random stimulus generation. Borrowing from 
classical signal-processing models, Vera uses a data source and a series of filters to transform and ma- 
nipulate random data feeds into the form required to execute adequate tests. 




The signal source is a random-number generator, while the filters can be configured to give any charac- 
teristic required by the data set. These facilities lead to test sets that are easy to understand and straight- 
forward to develop. 

Vera incorporates these stimulus generators into its object-oriented framework, creating a succincu cle 
gant, and powerful means of capturing data sets with an intrinsically random structure. Further, as ob- 
jects, multiple stimulus generators can be instantiated and randomized independently. " 
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Having extended objects to incorporate random variables, Vera also delivers a mechanism for packing 
and unpacking key members of an object. This provides a simple, straightforward mechanism for doing 
the type of data re-organization, such as generating, sending, receiving and analyzing data packets, that 
are common within many test environments. 

9.2 Stimulus Generation Overview 

Vera stimulus generation is divided into two major components: packet generation and data packing. 
Each is used within the object-oriented methodology to facilitate its use and re-use. 

Vent's random packet generation uses the class constructs within object oriented programming. Class 
variables normally associated with standard packet generation are declared as random variables. Then 
each instance of the packet generator is randomized by calling Vera's predefined randomization method. 
This enables you to create multiple stimulus generators, randomized separately, using a single genera- 
tion class. 

Once Vera generates random stimuli, these stimuli arc then filtered through constraint blocks. Con- 
straint blocks are analogous to signal filters. They control the range of values that randomized variables 
can assume. Their use allows you to narrow the focus of tests to achieve adequate coverage with a max- 
imum efficiency. 

In addition to random packet generation, Vera provides a means to set random variables to all the pos- 
sible boundary conditions. This provides another mechanism with which you can control and direct test 
generation. 

The second component of Vera's automated stimulus generation capabilities is the packing and unpack- 
ing of data into bit streams. Vera again makes use of the object-oriented framework by including class 
methods to handle the packing and unpacking of data. Further, Vera defines several attributes for class 
members that are used to determine how data is packed and unpacked. 

Together, these two components provide the means to generate and manage randomized data feeds in a 
controlled manner. 

9.3 Random Packet Generation 

Random packet generation is a specific implementation of Vera's packet generation capabilities. It con- 
sists of two major aspects: random variables and constraint blocks. 

9.3.1 Random Variables 

Variables are made random using the rand and randc keywords in the variable declaration. The syntax 
to declare a random variable is: 

rand variable; 

rude variable: .. ... 
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Vera supports the randomization of variables of type integer, bit, and enumerated type. You can also 
randomize objects as well as arrays of integers, bits, enumerated types, and objects. 

Associative arrays can be randomized, but you must specify the size of the array at runtime. For exam- 
ple: 

rand type array^name [ ] assoc_nixe num_bytes; 

nuntjbytes - Nuntjbytes specifies the number of elements in the array that will be randomized. Note 
that the array size itself can be a random number. You can use elements of the array other than 
those specified, but only the specified elements are randomized. 

9.3-1.1 rand and randc 

Vera has two forms of random variables, which are specified with the rand and randc keywords in the 
variable declaration. 

Variables declared with the rand keyword are standard random variables. Their values will change ran- 
domly, and repeat values are allowed. 

Variables declared with the randc keyword are random-cyclic variables. A random-cyclic variable takes 
on all possible values before repeating any value. Random-cyclic variables can only be bit or enumerat- 
ed types, and are limited to a maximum size of 8 bits. This limits the range of values to those falling be- 
tween 0 and 255. 

9.3.1 .2 Active and Inactive Random Variables 

Vera provides the predefined rand.modeO method to control whether a random variable is active or in- 
active. All random variables are initially active. The syntax for the rand.modeO method is: 

obiect_name.randjnod« {switch t, vaxiahle_name t, index] 1 ) ; 

object name - The object jtame is the name of the object in which the random variables are defined. 

switch - The switch is either OFF or ON. OFF sets the specified variables to inactive so that it 
■ J isnotehfoix^onsubs^uentca^^ 

active so that they are randomized on subsequent calls to the randomizeQ method. , r 

variable jtame - The variablejname is the name of Ac variables to be made active or 

inactive/The variable name can be the name of any variable in the class hierarchy. If no 
variable name is specified, the switch is applied to all variables within the specified object. 

index - THe index is an optional array index. Omitting the index results in all the elements of the array 
being affected by the call. A -1 index value is treated the same as index omission. 

The rand_modeO method returns the value of switch (either OFF or ON) if the change is successful. If 
the specified variable does not exist within the class hierardiy; the method returns a -1. If the specific 
variable exists but is not declared as rand or randc, the function returns a -1. 
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A special case for the switch argument is the REPORT keyword. Using REPORT will return the state 
of the specified constraint (either OFF or ON). The variable name and array index (if the variable is an 
array) must be specified for a REPORT. 

For example: 

class Packet { 

rand integer source_value, dest_value; 
constraint filterl { 

source_value > 2 * m; 

dest_value <= 2 * m + 17; 

) 

} 

Packet packet_a = new; 

integer ret = packet_a . rand_mode (OFF, *source_value* ) ; 
/ / ... other code 

ret = *packet_a . rand_mode (ON, *source_value* ) ; 

This example first makes the variable source_yalue inactive (OFF) and returns OFF to the variable ret. 
Then it makes the variable sourcejvalue active (ON) and returns ON to the variable ret. 



yj 9.3.2 randomizeO 

1* Variables are randomized using the randomizeO class method. The syntax to randomize an object is: 

H objec t_name . randami ro(); 

S3 

n j objectjnome - The object_nome is the name of the object in which the random variables have been 

Ci declared. 

"ksht . ... 

The randomizeO class method generates random values for all random and random-cyclic variables 
within the specified class instance. If there are random objects within the class instance, calling the ran- 
domizeO method also invokes their object.randomizeO methods. Thus, all random variables and ob- 
jects within a random object are randomized when the class instance is randomized. 

1 When associative arrays are randomized, only elements within the specified range are randomized. Ele- 
ments outside of this range are not randomized, t 

Random variables declared as static are shared by all instances of the class in which they are declared. 
Each time the randomizeO method is called, the variable is changed in every class instance. 

The randomizeO method returns a I if it successfully sets all the random variables and objects to valid 
values. If it does not, it returns a 0, which typically indicates a problem with the constraints. If the ran- 
domizeO call fails, any random variables set up until the failure retain their setting. If an object has no 
random variables any where in its inheritance hierarchy (no random variables or sub-objects) or if all of 
its random variables are inactive, the randomizeO function returns a 1. v ;-*..-.■ ■ 
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The randomize() method is implemented using the randomO system function. Thus, executing ran- 
dom(seed) affects the sequence of random numbers generated by randomizeO. 

For example: 

class Packet { 

local integer sequence; 
local randc bit {5:0] dest_addr; 
protected rand integer src_addr; 
static rand integer time_origin; 
rand Payload data_part; 

} 

This class definition declares a random-cyclic variable, dest_addr, a random variable, src_addr t a 
random variable, time_origin t and a random object, data_part . To randomize an instance of class 
O Packet, call the randomizeO method: 



fll Packet p = new 



O 
yi 



int success; 
Packet p = n 
success =p . randomize ( ) ; 



9.3.2.1 Randomization Usage Details 

The code for the pre-defined randomize method follows this pattern: 
virtual function randomize (integer flag = 1) 



{ 

int success = 1; 

if (flag ==1) 

this.pre_randomize() ; 

if (flag ==1) "* <: " :!! 

// Randomize the rand and randc member variables .(except 

// nested objects) of ."this' object and all its .ancestors, . 

// subject.., to the active constraints. 

// Set success e JO if it could not find a valid value for one. 

if (success == 1) 

success = super- randomize ( 0 ); 

while (success ==1) 

// For each nested object in •this' that is rand, do: 
. ... success = . nestecLobject. randomize ( .1 ); f , 

if (flag == 1) ?: ' ;MP - " 

t^s.post^randomizeO; ....... s .. ir . ^ .. ^, !>: , : ,, :;v , . v nf , k 
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randomize = success; 

} 

task pre_randomize ( ) 
{ 

super . pre_randomize () ; 

} 

task post_randomize ( ) 
{ 

super. pos t_randomi ze () ; 

) 

Notice that the flag parameter of super. randomize is 0, so that it will not call pre.randomizeO and 
post_randomize(). 

Also notice that the non-object member variables of "this" class instance and all its superclasses, back 
to the base class, are randomized at the same time. Random values are assigned in an order determined 
by the constraints, rather than by whether the rand or randc variable belongs to this class or a super- 
class. This allows enforcing a constraint like "super . j < 2 * this . i ; " f where both super . j and 
this . i are random variables, and where super . j can be given its random value only after this . i 
has been given its random value. 

Finally, notice that nested objects are randomized after the non-object variables. This allows variable- 
size arrays of nested objects, since the size of an associative array (as far as packing and randomizing 
are concerned) can depend on one or more random variables. 

You can write your own version of the randomizeO function. However, if you write your own version 
of randomizeO for a particular class, the rand and randc variables in the class arc not automatically 
set, and any constraints declared as part of the class are not enforced. 

If your randomizeO method calls the pre-defined super.randomizeO, with the flag parameter set to 
1 (or omitted), the rand and randc variables in this superclass and in its superclasses will be random- 
ized, using the constraints in this superclass and its ancestors. . 

If the class with your randomizeO has descendants with the pre-defined randomize ( ) , calling the de- 
scendants randomize function (with the flag parameter set to 1 or omitted) will affect variables in the 
descendant class and its superclasses, up to but not including the class with your randomizeO* using 
the constraints in those classes. Your randomizeO will be called, with the flag parameter set to 0. 

The randomizeO* p re_randomizeO and post.randomizeO methods must be public. 

9.3.2.2 Using randomizeO on Object Lists 

Vera allows you to create lists of objects, which enables you to initialize non-random variables that con- 
strain random variables. 

This is an example of using the randomizeO function on a list of objects: * ' 
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class ListClass 
{ 

integer id; 
rand bit [3:0] b; 
rand ListClass next; 

task new (integer new_id) 
{ 

id = new_id; 
next = null; 



function ListClass appencLone (integer new_id) 
{ 

next = new (new_id) ; 
append_one = next ; 

} 

// These examples illustrate the order the list objects 
/ / are randomized in . 

task pre_randomize ( ) 
{ 

printfCIn ListClass pre_randomize: object %0d\n', id); 

) 

task post_randomize () 

{ ^ 

printfCIn ListClass post_randomize: object %0d: b is %0h\n',id, b) 

> 

task print_list() 
{ 

printf ( 'ListClass object %0d; b is %0h\n - , id, b) ; 



task DoListO 
{ 

integer i = 1; 
integer success; 
ListClass head, tail; 

// Create a list of objects with sequential id's, 
head = new( i++ ); 
tail = head.appen<3Lone( i++ ); 
tail e tail.appen<3Lone( i++ ); 
tail = tail . appendLone ( i++ ); 
tail = tail.append_one( i++ ); 



} 



if (next != null) next .print_list ( ) ? 
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// Show the list, with variables not yet randomized. 

printf (• In DoList, the list before randomization is:\n'); 
head.print_list ( ) ; 
printf C\n-) ; 

// Invoke randomize on the head of the list. It will randomize 
// any non-object member variables ("b* in this example), then it will 
// invoke randomize on any object member variables ('next" in this 
// example). This will be repeated automatically until it encounters 
// the tail of the list, where 'next* is null. 

success = head. randomize () ; 

if (success != OK) printf ( "randomize failed in DoList\n"); 

// Show the list, with variables set to random values, 
printf ( '\nThe list after randomization is:\n*); 
head.print_list () ; 
printf C\n*) ; 



9.3.2.3 Using randomize() to Create Arrays of Variable Size 

Vera allows associative arrays, which can have very large indexes despite being a sparse array because 
elements are created when they are referenced. However, if an associative array is declared to be ran- 
dom, the number of its elements that are assigned values by the randomizeO function must be speci- 
fied. This expression can include random variables. Note that with this setup, constraints should be set 
up to force a non-negative value. 

This is an example of using randomizeO to create an array of variable size: 

♦define FACTOR 2 

# define - ORDINARY_SIZE 3 

# define MAX_SMAL.L_ARRAY_SIZE 7 

class SmallClass 
{ 

rand bit 12:0] small_var; 

} 

class ArrayClass 
{ 

// All these variables are random, 
rand 
{ 

integer m, n; 

integer ordinary [ORDINARY_SIZE] ;// ordinary array ; 
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bit [7:0] b_array [] assoc_size FACTOR * m;// associative array 
SmallClass small_array [] assoc_size n; // assoc. array of objects 

} 

// Constraint blocks are class members, just as the properties 
// (variables) and methods (tasks and functions) in a class are 
// class members. Constraints must follow the variables, 
// but come before the tasks and functions, of a class. 

constraint size_cons 
{ 

m >= 0 ; m <= 3 ; 

n >= 1; n < MAX_SMALL_ARRAY_S I ZE ; 

) 

task new() 
{ 

// Objects must be instantiated before they can be randomized. 
// Here, instantiate the maximum number of SmallClass objects ■ 
// that might be randomized in small_array. 

integer i; 

for (i = 0; i < MAX_SMALL_ARRAY_SIZE ; ++i) 
small_array[i] = new; 

task print_array ( ) 
{ 

integer i; 

printf ("m is %0d, n is %0d\n - , m, n) ; 
for (i = 0; i < ORDINARY^ SIZE ? ++i) 

printf ( -ordinary [%0d] is %0d\n', i t .ordinary [i.l ) ; 
for (i = 0; i < FACTOR * m; ++i) 

printf (•b.array[%Odl is %h\n", i, b_arraytil); 

for (i 0; i < n; +ti> : . • 

printf Csmall_array[%0dj .small_var is %b\n - .i, 
small_array[i) „small_var) ; 

} • 
} ' 
task DoArrayO 

{ . 
integer success; 
ArrayClass a; 

a = new ( ) ; 

success = a.randomizeO ; 

if (success != OK) printf C randomize failed in DoArray\n-); 
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printf ("In DoArray, ArrayClass values after randomize () call:\n'); 
a.print_array ( ) ; 
printf C\n') ; 

} 

9.3.3 Constraint Blocks 

The values of random variables can be controlled using constraint blocks. Constraint blocks limit the 
set of legal values that random variables can assume. These constraints are enforced by the random- 
izeQ class method. 

Constraint blocks are class members. They are defined within the class to be randomized. They must be 
defined after all the variable declarations in the class and before all the task and function declarations in 
the class. The syntax to declare a constraint is: 

constraint cons train t^name { contraint^expressions } 
constraintjname - The constraint jname is the name of the constraint block. 

constraint ^expression - The constraint ^expressions are the conditional expressions that limits random 
values. It is a series of expressions that are enforced when the class is randomized. Constraint 
expressions are of the form: 

random_variable operator expression; 

random ^variable - The random _yariable parameter specifies the variable to which the constraint is 
applied. 

operator - The valid operators for constraints are: <, <=, =, >=, >, !=, =, !=, =?=, and !?=. You can 
also use in, !in, and dist for distribution sets. 

expression - The expression parameters can be any valid Vera expression with the following exceptions: 
;• You cannot call a task or function. . 

• Pre- and post-Operators, like are not allowed. 

^ If the random variable is cyclic, the expression cannot contain any random variables. 

• Cyclic constraints are not allowed (for example, A < B; B < 2 * A). 

• The specified random variable cannot appear on both sides of the expression. 

• The specified random variable must be' a member of this class or one of its 
antecedents. 

• Expressions cannot include nested objects of this class, its superclasses or 
descendants - to preclude recursion. 

• Expressions cannot include random member variables of nested objects. 

If constraints in different classes in the inheritance hierarchy have the same name, the constraint in the 
lowest level descendant is used. 

This is an example of a basic constraint block: 
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class Packet { 

rand integer source_value; 
constraint filterl { 

source_value < n + 3; 

source_value > 2 * m; 

) 

} 

This example defines a class Packet, declares the random variable source_yaIue t and defines the con- 
straint block filterl. The constraint block filterl limits the range of values of source jvalue to 
those values falling between (n+3) and (2*m), where n and m are arbitrary global variables. 



9.3.3.1 Distribution Sets 

Distribution sets specify ranges of values and may assign weighted probabilities to them. The syntax to 
define a distribution set is: 

variable coannand {ranges}; 
variable - The variable is the random variable, which is controlled by the constraint 
command - The command can be in, !in, or dist 

ranges - Each of the ranges is a range of values specified by Vera expressions. Ranges are defined by 
specifying a low and high value, separated by a colon (:). If only a single value is specified, the 
range exists only of that value. Multiple ranges can be declared in the same, definition using 
commas to separate them. For example: 

data_addr in {5:7, 10, x+3:y*2); 
Expressions must follow the same rules random expressions follow regarding operators and variables. 

Note - A random variable can have only one distribution set (in, !in, or dist) 
associated with it 

r v- • - 4 ;\ . • • . 

in and !in 

The in command limits the values of the specified random variable to those within the defined range. 
For example: 

data_addr in {1:4, 6, 8:10}; 

This example declares a constraint such that the only values that data_addr can assume are 1 to 4, 6, 
and 8 to 10. 

An alternative to the in command is the lin command. The lin command specifies ranges of values that 
the random variable cannoi assume. For example: 

data_addr tin {1:4, 6, 8:10}; 
Synopsyslnc. r.- . 
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This example declares a constraint such that data_addr can assume all values except 1 to 4, 6, and 8 
to 10. 

dist 

The dist command limits the values of the specified random variable to those within the defined range, 
and it assigns weighted probabilities to the values. The dist command uses two operators to assign 
weights: := and :/. 

The := operator assigns the weight to each element in the list The zt operator distributes evenly the 
weight across the values of the range. For example: 

data_addr dist {5:7 := 10, 9 := 20}; 
data.addr dist {5:7 :/ 60, 9 :/ 40}; 

The first declaration assigns a weight of 10 each to 5, 6, and 7, and it assigns a weight of 20 to 9. The 
second declaration distributes a weight of 60 across the range 5:7, which assigns a weight of 20 each to 
5, 6, and 7. It also assigns a weight of 40 to 9. The probability that any single value is assigned to the 
variable is the individual weight divided by the total weight of the distribution. For example, using the 
first declaration, the probability that data_addr is assigned a value of 5 is 10/50 or 20%* 

9.3.3.2 Constraint Errors 

If constraints are set such that they can never be satisfied, a hard error occurs and the simulation termi- 
nates. This occurs with conflicting constraints that do not contain random variables or distribution sets 
that have no valid entries. 

If constraints that contain random variables cannot be satisfied, a soft error occurs. A 0 is returned and 
the simulation continues. A subsequent call to the randomizeO method may change the constraint vari- 
able, and the check is made again. 

In several cases, constraints that can never be satisfied are treated as soft errors. These include: =?=, 
!?=, in, !in, and dist constraints. 

9.3.3.3 Active and Inactive Constraints 

Vera provides the predefined constraint_mode() method to control whether a constraint is active or in- 
active. All constraints are initially active. The syntax for the constraint_modeO method is: 

object^name . cons tralnt _node (switch ( , cons train t_name\ ) ; 

object name - The objeajxame is the name of the object in which the constraint block is defined. 

switch - The switch is either OFF or ON. OFF sets the specified constraint block to inactive so that it 
is not enforced on subsequent calls to the randomizeO method. ON sets the specified constraint 
block to active so that it is enforced on subsequent calls to the randomizeO method, 
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constraint jname - The constraintjname is the name of the constraint block to be made active or 
inactive.The constraint name can be the name of any constraint block in the class hierarchy. If no 
constraint name is specified, the switch is applied to all constraints within the specified object. 

The constraint_inodeO method returns the value of switch (either OFF or ON) if the change is suc- 
cessful. If the specified constraint block does not exist within the class hierarchy, the method returns a 
.1. 

A special case for the switch argument is the REPORT keyword. Using REPORT will return the state 
of the specified constraint (either OFF or ON). The constraint name must be specified for a REPORT. 

For example: 

class Packet { 

rand integer source_value; 
constraint filterl { 

source_value > 2 * m; 

} 

} 

Packet packet_a = new; 

integer ret = packet_a.constraint_mode (OFF, filterl); 
// other code 

ret = packet_a. const rain t_mode (ON, filterl); 

This example first makes constraint filterl inactive (OFF) and returns OFF to the variable reU Then 
it makes constraint filterl active (ON) and returns ON to the variable ret. 



9.3.3.4 Void Constraints 

Vera allows you to assign a void value to constraints, which is useful using conditionals. The syntax is: 

randonuvariable operator {conditional) ? expression : void; 
conditional - The conditional can be any valid constraint expression. 

If the conditional evaluates to true, the constraint is set to the specified expression. If the conditional 
evaluates to false, the constraint is made void, and the random variable is not affected by this con- 
straint Note that it could be affected by other active constraints. 

This is an example of several constraints used together 

rl >= (r2==0) ? 1 : void; 

rl >= (f2==l) ? 2: void; 

rl >= (r2==2) ? 4: void; 

rl >= (r2==3) ? 8: void; 

rl >= (r2>3) ? 16: void; 

This example sets rl greater than or equal to 1 if r2 is equal to 0. If r2 is equal to 1. rl is set so that it 
is greater than or equal to 2. The progression continues through all of the conditions. 
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9.3.3.5 Static Constraint Blocks 

You can define a constraint block as being static by including the static keyword in the definition. The 
syntax to declare a static constraint block is: 

static constraint cons train t^name { contraint_expression } 

If a constraint block is declared as static, calls to constraint_modeO affect all instances of the specified 
constraint in all objects. So if a static constraint is set to OFF f it is OFF for all instances. 



9.3.3.6 Constraint Interdependencies 

In Vera, a constraint has a single random variable on the left side of an operator. The expression on the 
right side of the operator may include other random variables. The randomizeO function sorts the ran- 
dom variables before randomizing to ensure that a random variable on the right side of a constraint has 
been assigned a value before assigning values to variables that depend on those constraints. 

This is an example of using constraint interdependencies: 

#define NUM^R 9 

class Constraints lass 



{ 



rand integer r [NU14_R] ; 

constraint conl 

{ 



// r(l 
rtO 
r[l 
r[l 

// r[3 

r[2 
r[3 
r[3 
r[4 
r[4 
r[5 
r[5 

// r[7 

r[€ 
r[8 
r[8 



and r[2] will be assigned values before r[0) 
>= r[l] + 2 * r(2]; 

> 0; 

< 10; 

, r[4], r[5], r{8] will be assigned values before r[2] 

in { r[3] : r[3) «■ 4. r[4) - 2 : r[5], r[8] }; 

> 0; ' '" ' •* - ' 
•<,5;.., : 

>• -20/ .... . "* ( . 

< -10; 

> 3; 

< 12; 

and r(8] will be assigned values before r[6] 

== r[7] / r[8]; 

> 1; 

< 5; 



// r[8] will be assigned a value before r [7] 
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r[7] > r[8]; 

} 

task print_vars ( ) 
{ 

integer i ; 

for (i = 0; i < NUW_R; 

printf Cr[%0d] is %d\n" , i, r[i]); 



integer success; 
ConstraintClass c; 

c = new ( ) ; 

success = c . randomize ( ) ; 

if (success != OK) printf ( •randomize failed in DoConstraint\n* ) ; 
printf ('In DoConstraint, ConstraintClass values after randomize () 
call:\n-); 
c « print_vars ( ) ; 
printf C\n') ; 



There are several ways to dynamically modify constraints on randomization: 

• Within a constraint, the ?: construct can be used like an if statement to indicate 
which of two values should appear on the right side of the constraint 

• A constraint block can be made active or inactive by using the constraint_modeO 
function. Initially, all constraint blocks are active. Inactive constraints are ignored by 
the randomizeO function. 

• Random variables can be made active or inactive using the rand_mode0 function. 
Initially, all rand and randc variables are active. Inactive variables are ignored by 
the randomizeO function. v 

• The weights in a dist constraint can be changed, affecting the probability that 
particular values in the set are chosen. 

This is an example of dynamically modifying constraints: 

class DynamicClass 
{ 



) 

} 

task DoConstraintO 



{ 



9.3.3.7 Dynamic Constraint Modification 



bit 15:0] counter; 
rand { 

bit(7:0] byte; 

bit [3:0] nibble; 
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bit [15:0] half_word; 
bit [31:0] word; 

} 

// If counter is > 10, randomize will give nibble a value that 
// satisfies 'nibble =?= 4'bl0xx". If not, randomize will give 
// nibble a value that satisfies -nibble =?= 4'bOxxlV 

constraint con_question 
{ 

nibble =?= ( (counter > 10) ? 4'bl0xx : 4'bOxxl ); 

} 

#ifdef VERA_4_0 

// If nibble is 0, randomize () will produce a value for byte that 
// satisfies "byte- == 3", that is, it will set byte to 3. 
// If nibble is 1 or 2, it will set byte to 5. 

// If nibble is 3 or 4, it will set byte to (nibble | 4'bl000) . 
// If nibble is between 5 and 8, it will set byte to. 7. 
// If nibble is greater than 8, it will set byte to a random value 
// less than 12. 

constraint con_void 
{ 

byte == ( (nibble ==0) ? 3 : void ); 

byte == ( (nibble == 1 | | nibble == 2) ? 5 : void ); 

byte == ( (nibble == 3 | | nibble == 4) ? nibble | 4'bl000 : void ) 

byte == ( (nibble >= 5 && nibble <= 8) ? 7 : void ); 

byte < ( (nibble > 8) ? 12 : void ); 
} . * 

fendif 

// The next two constraint blocks conflict with each other — that is, 
// there is no possible value for word that can satisfy both con_zero 
// and con-ones. . The caller will make . sure that,, only., one, of these two 
// is active at a time. ■';:.'.'...**• 

constraint con_zero 
{ 

word =?= { half_word, byte, nibble, i4'b00xx >; 

} 

constraint con_ones 
{ 

word =?= { half_word, byte, nibble, 4'bllxx ); 

} 
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task new() 
{ 

counter = 0; 

} 

// The pre_randomize ( ) task itself will modify counter, which will 
// affect which constraints apply to the random variables. 

task pre_randomize ( ) 
{ 

++counter; 

} 

task print_vars ( ) 
{ 

print f ('counter is %d\n", counter); 
printf Chalf_word is %h\n" , half_word) ; 
printf ("byte is %h\n" , byte); 
printf ("nibble is %h\n - , nibble); 
printf ('word is %h\n" , word); 

) 

} 

#def ine LOOP_MAX 20 

task DoDynamicO 
{ 

integer i, j, success; 
DynamicClass d; 
d = new ( ) ; 

// One of the two conflicting blocks must be made inactive. 
// After half of the loop iterations below are completed, this 
// one will be re-activated and the other one made inactive. 
// (Calling constraint^ mode (OFF) will return OFF unless it is 
// unable to find a constraint block with the specified name, 
// e.g. due to a spelling error.) 

if (d.constraint_mode (OFF, •condones") .!= OFF) 

printf ( • cons traint_mode ( OFF ) failed, on condones \n' ) ; 
printf (*In DoDynamic, turned condones constraint OFF. \n\n'j; 
for (i = 0; i < LOOP_MAX; ++i) 
{ 

success = d.randomizeO ; ' ^ 

if (success != OK) printf ( ■ randomize failed in DoDynamic, i %0d\n",i); 
printf (•DynamicClass values after randomize () call with 

.«■:-....,.- ^'.:,:Tf: ^ i= %6d: \n" ; i) ; • ft:* .>Vi . r.V.> " >-W 
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printf ("\n"); 

if (i == LOOP_MAX / 2) 

{ 

if (d.constraint_mode (ON, "con_ones - ) != ON) 

printf (" const rain t_mode (ON) failed on con_ones\n" ) ; 

if (d.constraint_mode (OFF, "con^zero") •= OFF) 

printf C.constraint_mode(OFF) failed on con_zero\n« ) ; 

printf C\nTurned con_ones constraint ON, con_zero OFF.\n\n"); 

) 

} 

#ifdef VERA_4_0 

// Now inactivate all the random variables, leaving them at whatever 

// values they now hold, except 'nibble" . Any constraints with inactive 

// random variables on the left side are ignored. 

if (d.rand_mode (OFF) != OFF) 

printf ( "rand-mode (OFF) failed\n"); 
if (d.rand_mode (ON, "nibble") != ON) 

printf ("rand-mode (ON) failed on nibble\n"); 
printf ("\nTurned all random variables except nibble OFF.\n\n"); 
for (j = 0; j < 4; ++ j ) 
{ 

success = d. randomize () ; 

if (success != OK)printf( "randomize failed in DoDynamic, j %0d\n",j); 
printf ("DynamicClass values after randomizeO call with 
j=%0d:\n", j); 
d.print_vars ( ) ; 
printf C\n"); 

) " " 

#endif 



9.3.4 Boundary Conditions 

Vera*s boundary condition capabilities arc used to generate values that match the upper and lower limits 
of a random variable's valid value range. This is particularly useful because many design flaws occur at 
the boundary conditions. Boundary conditions are generated when the system function boundaryO is 
called. The syntax to call the boundaryO function is: * 

objec t_name . boundary ( whi ch) ; 
object jname • The objectjname is the name of the object on which the boundaryO call is being made. 

which - The which argument must be either FIRST, which sets the effected random values to their first 
boundary condition, or NEXT, which cycles through each subsequent boundary condition. 
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Boundary conditions for random variables are determined by the constraints on a random variable. For 
instance, examine this constraint block: 

class foo { 

rand integer a, b, c; 
constraint cl { 

a>=10; a<=20; 

b>=0; b<=100; 

c in {1:15, 32:63); 

> • • ----- ^ 

} 

For this constraint block, a has the boundary conditions 10 and 20, b has the boundary conditions 0 and 
100, and c has the boundary conditions 1, 15, 32, and 63. This results in 16 different boundary condi- 
tion combinations that would be generated with the boundaryO system function. 

The boundaryO method treats rand and randc variables the same way. Note that you can also use ran- 
dom variables within the constraints so that boundary conditions are dependent on random values. 
However, if the values of the right-hand side of a constraint change while the boundaryO method is be- 
ing invoked, the boundary conditions are determined by the values at the time of the function call. Sub- 
sequent changes to the conditions do not affect the current call, but they will affect future calls. 

When the boundaryO function is called, all random variables within the specified class instance are set 
to their boundary conditions. If the which argument is set to FIRST, the first set of boundary conditions 
are used. If the which argument is set to NEXT, the next set of boundary conditions in the sequence is 
used. The sequence of boundary conditions is influenced by a number of factors, including the order of 
variable declaration and the order they are named in the constraints. ; . 

If there are random objects within the class instance calling boundaryO, it also invokes object.bound- 
aryO. Thus, nested objects and extended classes are affected by calls to boundaryO- Random variables 
declared as static are shared by all instance of the class in which they are declared. Each time the 
boundaryO method is called, the variable is changed in every class instance. 

When the boundaryO function is called, it returns a 1 (or OK) each time it successfully sets the random 
variables to their boundary conditions. If one or more variables cannot be set due to conflicting re- 
straints, it returns a 0 (or FAIL). If the last set of conditions has been set, it returns a 2 (br OKiLAST). 
If an object has no random variables anywhere in its inheritance hierarchy (no randcnn variables or sub- 
objects) or if all of its random variables are inactive, the boundaryO function returns a NOJVARS. 

The boundaryO function makes calls to pre.boundaryO and postj>oundary0 much in the same way 
that randomizeO calls pre_randomize0 and post_randomize0- 

This is an example of the boundaryO system function: 

program b 
{ 

integer success; , r . . 

my-object obj = new; 
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success = obj .boundary (FIRST) ; 

while (success==OK) success = obj . boundary (NEXT) ; 

if (success ! =0K_LAST) print f ( m Boundary problem (%0d)\n*, success) ; 

) 

This example defines the object obj . The random variables within obj are set to their initial boundary 
conditions with the first boundaryO call. The while loop sets them to their other boundary conditions. 

9.4 Data Packing and Unpacking 

Data packing consists of the packing of data fields into a serial bit stream and the subsequent unpacking 
of the bit stream to re-form a data structure. Data packing is particularly useful for sending packets over 
serial communication streams and then converting back to a packet structure. 

Again, data packing is integrated into the object-oriented framework of Vera. Vera defines several class 
methods that are used to pack and unpack data. Vera also provides a set of attributes for class members 
that designate how data is to be packed and unpacked. 

There are two main aspects of data packing: property attributes and the pack and unpack class methods. 

9.4.1 Property Attributes 

Vera provides several property attributes that designate how data is to be packed and unpacked. These 
attributes include: 

• little_endian 

• big_endian 

• bit_normal 

• bit_reverse 

• packed , . ■ 

• unpacked 

The attributes little-endian, bit.endian, bit.normal, and bit_reverse can only be assigned to van- 
ables also assigned the packed attribute. These attributes can only be assigned to class variables; they 
cannot be assigned to class methods or constraints. . 

, When variable attributes are nested, the lowest level attribute overrides the higher level attributes. For 
example: 

packed bit_reverse ' ' 
{ 

integer i; 

bi t_normal s tr ing s tr ; 
unpacked 
{ 

integer k; 
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} 

integer n; 

} 

In this example, i and n are packed bit_reverse, sir is packed bit_normal, and k is unpacked. 
Iittle_endian 

Variables assigned the Iittle_endian attribute are packed least-significant byte first This is part of the 
default attribute settings. 

big_endian 

Variables assigned the big_endian attribute are packed most-significant byte first 
bit_normal 

Variables assigned the bit_normaI attribute are packed most-significant bit of each byte first This is 
part of the default attribute settings. 

b"rt_reverse 

Variables assigned the bit.reverse attribute are packed least-significant bit of each byte first 

. .... y... 

9.4.2 Packing Methods ? f 

The pack and unpack methods can be used to pack member variables of type integer, bit field, string, 
enumerated type, and objects into an associative array of type bit, and vice versa. Strings are packed as 
a sequence of bytes, with a zero-byte terminator. Uninitialized or unknown integers are packed as 32 
bits of *x\ Enumerated types are packed in up to 4 bytes. An associative array must have a size field 
specified before it is packed. Anything not within the size specification is not packed. J 

The syntax to pack data is: ** 

object__name* pack {array, index, left, right); ....... 

array - The array parameter specifies the array into which data is to be packed. The array can be an 
associative array of any bit width. „ ■ , , * n /» f. : 

index - The index parameter specifies the array index at which to start packing. 

left/right - The left and right parameters specify the number of bits on the left and right to leave 
unchanged in array[index). Normally, you initialize them to 0 before calling packO- 

The packO method returns the number of bits packed. It also updates offset, left, and right so that they 
can be used as arguments to subsequent packO calls when packing multiple objects into a single 
stream. 

This is an example of the packO method: 
Synopsys Inc. 
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integer nbits; 
integer offset = 0; 
integer left = 0; 
integer right =0: 
bit [7:0] stream[]; 

nbits = packet_head. pack (stream, offset, left, right); 
nbits+ = packet_body. pack (stream, offset, left, right); 

When the packO method is called, it begins by packing the first member it encounters. If an object's 
handle is encountered, then the packO method of that class is invoked. Packing an object handle that is 
null produces a warning, and nothing is packed for that nested object; that object handle should also be 
null when the containing object is unpacked. If a nested object's handle is not null when it is packed, 
the handle should also be non-null before it is unpacked; unpacking does not call new to create objects. 

9.4.3 Unpacking Methods 

The unpacking methods are analogous to the packing methods. The syntax to unpack data is: 
object_najne.unpack(array, index, left, right); 

The parameters have the same definitions as with packO- The array parameter should be set to the ar- 
ray into which data was packed. The index, left, and right are normally initialized to 0. They are then 
updated with each call to unpackO. This allows you to unpack multiple objects from a single array. 

You should generally unpack multiple objects from one array in the same order in which they were 
packed. For example: . 

x.pack( . . 
y . pack ( . - 
z .pack ( . . 
x . unpack (...) 
y . unpack (...) 
2. unpack ( . . . ) 

9.4.4 Pack and Unpack Example 

This is an example of the packO and unpackO methods: 
# include <vera_&ef ines .vrh> 
class Serial_Data_Type 

static integer inst_num = 0; - 
packed 
{ 

.^'C> : -...it-**.:'.. >\o rfi.:; ;L ...;-: 
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rand bit (19:0] bit_data; 
string comment; 

} 

task new() 
{ 

integer status ; 

status = this.randomizeO ; 
if ( 'status ) 

error ( "Randomize failed! \n" ) ; 

inst_num++; 

sprintf (comment, 'This is serial packet instance number %0d having 
data %b ■ , inst_num, bit_data ) ; 
}//end task new 

CI } 

\\ program packed_test 

m { 

p Serial_Data_Type sdata_arr [5] ; 

□ bit data_stream[j; // does not have to be byte stream 

yl integer i, g_offset, g_left, g_right; 

~" printf ("\n\nPacking data \n'); 

y g_offset = 0; g_left = 0; g_right = 0; 

k~ for ( i = 0; i < 5; i++ ) 

b h { 

sdata_arr[i] = new; 



E=i5 
E U 



printf (" %s \n' ( sdata_arr [ i ). comment ); 

void = sdata_arr{i]-pack ( data.stream, g_offset, g_left. 
g_right ) ; : • . • . 

}//end for ' ! i: 

printf ( * \n\nUnpacking data in order \n->; 

g_offset = 0; g_left = 0; g_right = 0; 

for ( i = 0; i < 5; i++ ) 

( 

void = sdata_arr[i] -unpack ( data_stream, g_offset, 

g_left, g_right ); 
printf (" %s \n", sda ta_arr I i ] . comment ); 
}//end for 



9.4.5 Details of Pack and Unpack 

The code for the pre-defined packQ method follows this pattern: 
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virtual function integer pack (var bit(N:0] array[], 

var integer offset, var integer left, var integer right, 
integer flag = 1) 

{ 

integer nbits = 0; 

if {flag == 1) 

this . pre_pack ( ) ; 

nbits = super. pack (array, offset, left, right, 0) ; 

// code to pack the member variables of "this" that are marked packed 
// in order, including nested objects — adding to nbits 

if (flag ==1) 

this .post_pack( ) ; 

pack = nbits; 
* 

task pre_pack() 

super. pre_pack() ; 
task post_pack() 

super. post_pack() ; 

Notice that the pack method calls the pack() of its superclass before packing member variables of the 
current class. Then, unless the superclass's packO method has been overridden, it calls its own super- 
class's packO. Thus, the packing operation ultimately begins with the base class and works its way 
down the hierarchy, so that data associated with the base class is packed before data associated with its 
descendants. Notice also that the flag parameter of super . pack is 0, so that it does not call pre_pack() 
and post_pack(). 

The unpackO, prejackO, and post_pack() methods follow this same pattern. Each of these methods 
must be public. 

If you override the pre-defined method, you must specify a particular bit width, which will be inherited 
by all the class's descendants. 
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Example 4: Stimulus Generation 

This is an example using automated stimulus generators. The example includes these features: 

• Random packet generation 

• Constraints 

This example includes these files: 

• globaldef.h 

• memCtlif.vrh 

• stimgeruvr 

• RUN (a run script) 

The RUN script generates a header file for stimgen.vr. 

globaldef.h 

#ifndef FILE_GLOBALDEF_H 
#define FILE_GLOBALDEF_H 

enum MEM_SEG = MEM_SEG0, MEM_SEG1 , MEM_SEG2; 

enum COVERAGE_VAL_OPT = GENERIC_COV, STATE_COV, TRANS_COV; 

# define W_NOOP 1 

♦define W_FLUSH_CACHE 2 , 
# define W_BURST_R£AD 8 
♦define W_SINGLE_READ 4 
tdefine W_BURST_WRITE 7 
♦define W_SINGLE_WRITE 3 

♦endif 

memCtl.if.vrh 

♦ifndef INC_MEMCTL_IF_VRH 
♦ define INC _J!EMCTL_IF_VRH 
♦define INPOT_EDGE PSAMPLE 
♦define OUTPUT.EDGE PHOLD 
♦define OUTPUT_SKEW ♦! 



Synbpsyslnc. 



202 Example 4: Stimulus Generation 



Vera 4.0 User's Manual 



interface memCtl 
{ 

input [3:0] mc_state INPUT_EDGE ; 

inout [2:0] cmd INPUT_EDGE OUTPUT_EDGE OUTPUT_SKEW ; 
inout cache_hit INPUT_EDGE OUTPUT_EDGE OUTPUT_SKEW ; 
inout cache_dirty INPUT_EDGE OUTPUT_EDGE OUTPUT_SKEW ; 
input elk CLOCK; 
} // end of interface memCtl 

port mport 
{ 

mc_state; 
cmd; 

cache_hit; 
cache_dirty; 
}//end mport 

bind mport mbind 
{ 

mc_ state memCtl ,mc_s t ate; 
cmd memCtl . cmd; 
cache_hit memCtl. cache_hit; 
cache — dirty memCtl . cache„dirty; 
}//end bind 



# include <vera_de fines .vrh> 
# include • memCtl. if .vrh - 
•include 'globaldef .h' 

// Random Obj t_Addr 

// consists of random type members concerning the address values 

// the 3 constraints have to be exclusively turned on, to select 
// the value of address being generated, otherwise, it will 
// give error of conflicting constraints 

class t_Addr 
{ 

rand bit [15:0] tag; 
randc bit [7:0] cache_idx; 
constraint addr_seg0_con 
{ 



lendif 
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tag >= 16'h0000 ; 
tag < 16'h0100 ; 



} 



constraint addr_segl_con 



tag >= 16'h0100 ; 
tag < 16'h0200 ; 



constraint addr_seg2_con 
{ 

tag >= 16'h0200 ; 
tag < 16'h0300 ; 

} 

}//end class t_Addr defn 

// Random Obj which contains t_Addr type of obj as member 

// members include the t_Addr type obj, cache_hit, cache_dirty 

// member methods include 

// gen_addr : do a randomize on the addr obj 
// incre_addr : increase the addr value 
// exec__cmd : execute the command type 

// test_boundary : test all boundary conditions with a 
// certain segment with a certain command 

class t_CmdPacket 
{ 

// Non-Rand Stuff 

bit [2:0] command; 

// rand members 

rand 
{ 

t_Addr mem_addr; 
bit stim_cache_hit; 
bit stim_cache_dirty; 

} 

local task drive_memCtl with mport () ; 
task new ( ) ; 

task gen_addr ( MEM_SEG which_mem_seg ) ; 
task incre_addr ( ) ; 

task t es t_boundary with mport (MEK_SEG which_mem_seg,bit {2 : 0] do_cmd) ; 
task exec_cmd with mport ( bit (2:0] do_cmd) ; 
}//end class t_CmdPacket .defn 
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task t_CmdPacket : :new () 
{ 

mem_addr = new; 

} 

task t_CmdPacket : : gen_addr ( MEM_SEG which_mem_seg ) 
{ 

integer status; 
case ( which_jmem_seg ) 
{ 

MEM_SEG0 : 
{ 

void = mem_addr.constraint_.mode ( 
void = mem_addr.constraint_mode ( 
void = mem_addr. const raint_mode ( 

} 

MEI^SEGl : 
{ 

void = mem_addr. const rain t_mode ( 
void = mem_addr. cons train t_mode ( 
void = mem_addr. const raint_mode ( 

} 

MEM_SEG2 : 
{ 

void = mem_addr.constraint_mode ( 
void = mem_addr .const raint_mode ( 
void = mem_addr. cons train t_mode ( 

) 

}//end case 

status = this. randomize () ; 
if ( status == 0 ) 

error ('Randomize failed!\n"); 
} //end gen_addr 

task t.CmdPacket: : test_boundary with mport (MEM_SEG which_men_seg, 
bit {2:0] do_cmd) 

{ 

integer status; 

case ( which_men_seg ) 

{ 

MEK_SEG0 : 

{ ■ ... ■ : 

void = mem_addr, constraint _mode ( ON, •addr_segO_con" ) ; 
void = men_addr. const raint_mode ( OFF, .. •addr_segl_con* ); 
void = menuaddr . cons traint_mode ( OFF, •addr_seg2_con ; ) ; 



ON, •addr_segO_con" ) ; 
OFF, •addr_segl_con' ) ; 
OFF, •addr_seg2_con" ) ; 



OFF, "addr_segO_con* ) ; 
ON, *addr_seg3_con* ) ; 
OFF, "addr_seg2_con' ) ; 



OFF, •addr_segO_con' ) ; 
OFF, "addr_segl_con' ) ; 
ON, •addr_seg2_con* ) ; 
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) 

MEM_SEG1 : 
{ 



void = mem_addr.constraint_mode 
void = niem_addr.constraint_mode 
void = mem_addr.constraint_mode 



( OFF, •addr_segO_con' ) ; 
( ON, •addr_segl_con" ) ; 
( OFF, •addr_seg2_con* ); 



} 

MEM_SEG2 : 
{ 

void = menuaddr . cons train t_mode ( OFF, •addr_segO_con• ) ; 
void = mem_addr.constraint_mode ( OFF, ■addr_segl_con« ); 
void = mem_addr . cons train t_mode ( ON, •addr_seg2_con- ) ; 

) 

}//end case 

status a this .boundary (FIRST); 

if ( status != FAIL && status <= OK_LAST ) 

exec_cmd with (get_bind() ) ( do.cmd ); 
else 

error ("unexpected failure in boundary call!\n"); 
while ( this. boundary ( NEXT ) != OK_LAST ) 
exec_cmd with <get_bind()) ( do_cmd ); 
}//end test_boundary 

task t_CmdPacket : : incre_addr ( ) 
{ 

this .mem_addr. tag += 32; 
}//end incre_addr 

task t_CmdPacket: :exec_cmd with mport ( bit [2:0] do_cmd ) 
( 

integer s tatus ; 
this . command = do_cmd; 
drive jnemCtl with (get_bind()) (); 
}//end task exec_cmd 

task t_CmdPacket: : drive jnemCtl with mport () 
{ 

61 $cmd = this, command; 

@0 $cache_hit = this .stim_cache_hit; 

60 $cache_dirty = thi6.stiro_cache_dirty; 

61 $mc_state == void; 
}//end task drive_memCtl 
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RUN 

#!/bin/csh -f 

rm -f *.vro core *.vshell >& /dev/null 
vera -cmp -g -h stimgen.vr 
if ($status) exit 1 




Synopsyslnc. 



Vera 4.0 User's Manual Chapter 1 0. Vera Stream Generator 207 



1 0. Vera Stream Generator 



This chapter introduces the Vera Stream Generator. It describes the powers of the VSG and details its 
use. This chapter includes these sections: 

• VSG Overview 

• Production Definitions $ 

• Production Controls 

• Value Passing 

1 0.1 VSG Overview 

The syntax for programming languages is often expressed in Backus Naur Form (BNF) or some deriv- 
ative thereof. Parser generators use this BNF to define the language to be parsed/ HoweVd; it is possi- 
ble to reverse the process. Instead of using the BNF to check that existing code fits the correct syntax, 
the BNF can be used to assemble code fragments into syntactically correct code. The result is the gen- 
eration of pseudo-random sequences of text, ranging from sequences of characters to syntactically and 
semantically correct assembly language programs. , ? ; /v 

Vera's implementation of a stream generator, the VSQ, is defined by a set of rules and productions en- 
capsulated in a randseq block. The general syntax to define a VSG code block is: qc. 

randseq (product! on_name) { 



production_.de fini tionl ; 
product! on_.de fini tion2; 



production^definitionN; 

When the randseq block is executed, random production definitions are selected and streamed together 
to generate a random stream. How these definitions are generated is determined by the base elements 
included in the block. : - r \:^ 

Any VSG code block is comprised of production definitions. Vera also provides weights, production 
controls, and production system functions to enhance production usage. Each of these VSG components 
is discussed in detail in subsequent sections. 

10.2 Production Definitions 

A language is defined in BNF by a set of production definitions. The syntax to define a'production is: 



- — «=- 
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product ionj_name : production_list; 
production jname - The production^name is the reference name of the production definition. 
production Jist - The productionjtist is made up of one or more production Jitems. 

10.2.1 Production Items 

One or more production items makes up a production list Production items are made of terminals and 
non-terminals. 

A terminal is an indivisible code element It needs no further definition beyond the code block associ- 
ated with it. Code blocks should be encapsulated in braces ({ }). A non-terminal is an intermediate vari- 
able defined in terms of other terminals and non-terminals. 

If a production item is defined using non-terminals, those non-terminals must then be defined in terms 
of other non-terminals and terminals using the production definition construct. Ultimately, every non- * 
terminal has to be broken down into its base terminal elements. 

Multiple production items specified in a production list can be separated by white space or by the OR 
operator (I). Production items separated by white space indicate that the items are streamed together in 
sequence. Production items separated by the I operator force a random choice, which is made every time 
the production is called. 

This is a simple example illustrating the use of production items: ■? 

main : top middle bottom; 
top : one | two; 
middle : three | four; 
bottom : five; 

The main production definition is defined in terms of three non-terminals: top, middle, and bottom. 
When the call is made to this random sequence, top, middle, and bottom are evaluated, and their defini- 
tions are streamed together. 

The top, middle, and bottom production definitions are defined in terms of terminals. The I operator 
forces a choice to be made between the one and two terminals and also between the three and four ter- 
minals. 

This sequence block leads to these possible outcomes: 

one three five 
one four five * 
two three five 
two four five 

This is an example of a full set of production definitions: 
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assembly_program: text_section data_section ; 
text_section: {print f ( * . text" ) ; } my_code ; 
data_section: {printf ( • -data" ) ; } data ; 
data: initialized_data | uninitializecLdata ; 
my_code: { /* Vera code */} 
initialized_data: { /* Vera code */ } 
uninitialized_data: { /* Vera code */} 

This example defines the production assembly _pro gram in terms of text_section and datajsection. The 
production text_section is then broken down to include the string ".text" and the non-terminal myjcode. 
The production datajsection is defined in terms of either of the two terminals initialized jdata and 
uninitialized jiala, the selection of which occurs when the randseq block is called The resulting output 

is: 

.text 

my_code output 
.data 

initializedLdata output OR uninitializecLdata output 

The myjcode, initialized_data, and uninitializedjdata outputs are determined by the code blocks asso- 
ciated with those productions. 

10.2.2 Weights 

Weights can be assigned to production items to change the probability that they are selected when the 
randseq block is called. The syntax to declare a weight is: 

production_name : weight production^item; 

weight - The weight must be in the form of Sc(expression) where the expression can be any valid Vera 
expression that returns a non-negative integer. Function calls can be made within the expression, 
but the expression must return a numeric value, or else a simulation error is generated. 

Assigning weights to a production item affects the probability that it is selected when the randseq block 
is called. Weight should only be assigned when a selection is forced with the I operator. The weight for 
each production item is evaluated when its production definition is executed. This allows you to change 
the weights dynamically throughout a sequence of calls to the same production. 

This is an example of a weighted production definition: ... 

integer_instruction : &(3) addLins true t ion 

| &(i*2) sub_instruction ; 

it*. 

This example defines the production integer ^instruction in terms of the weighted production items 
cddjnstruction and subjnstruction. If i is 1 when the definition is executed, there is a 60% (3/5) 
chance that oddjnstruction is selected, and a 40% (2/5) chance that subjnstruction is selected. 
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10.3 Production Controls 

Vera provides several mechanisms that can be used to control productions: if-else statements, case 
statements, and repeat loops. 

10.3.1 If-else Statements 

A production can be conditionally referenced using an if-else statement. The syntax to declare an if-else 
statement within a production definition is: 

product ion^ame : <if (condition) product ion^name else product ion_name> ; 
condition - The condition can be any valid Vera expression. 

If the conditional evaluates to true, the first production item is selected. If it evaluates to false, the sec- 
ond production item is selected. The else statement can be omitted. If it is omitted, a false evaluation ig- 

LJ nores the entire if statement 

til 

S j This is an example of a production definition that uses an if-else statement: 

JL' assemblyjblock : <if (nestingLevel > 10) seq_block else anyJblock>; 

y 

«f This example defines the production assemblyjblock. If the variable nestingLevel is greater than 10, the 

p I production item seqjblock is selected. If nestingLevel is less than or equal to 10, anyjblock is selected. 

rzrc . • '• 

S 

P 10.3.2 Case Statements 

Lk A general selection mechanism is provided by the case statement The syntax to declare a case state- 

nj ment within a production definition is: 

product ion^name : <ctie {primary^ expression) 
case ^expression : product ion^name 
case2^jexpression : product ion^name 

caseW_expression : production^name 

default : product ion^name ' > ; " " ' 

expression - The expressions can be any valid Vera expression or comma-separated list of expressions. 

The primary ^expression is evaluated when the production definition is executed. The value of the 
primary ^expression is successively checked against each case_expression. When an exact match is 
found, the production item corresponding to the matching case is executed, and control is then passed 
to the first line of code after the case block. If other matches exist, they are not executed. If no match is 
■ found, the default statement is executed. If no default statement is specified and no matches are fdlmd, 
control passes to the first line of code after the case statement without any production being executed. 

This is an example of a production definition using a case statement: 
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assembly_block : <case(i*3) 
0 : seq_block 
3 : loop_block 
default : any_block> ; 

This example defines the production assemblyjblock with a case statement The primary expression i*3 
is evaluated, and a check is made against the case expressions. The corresponding production item is 
executed. 

10.3.3 Repeat Loops 

The repeat loop is used to loop over a production a specified number of times. The syntax to declare a 
repeat loop within a production definition is: 

production_name : <repoat {expression) product ion_name> ; 

expression - The expression can be any valid Vera expression that evaluates to a non-negative integer, 
including functions that return a numeric value. 

The expression is evaluated when the production definition is executed. The value specifies how many 
times the corresponding production item is executed. 

This is an example of a production definition using a repeat loop: 

6eq_block : <repeat (random () ) integer_instruction>; 

This example defines the production seqJblocK which repeats the production item integer ^instruction a 
random number of times, depending on the value returned by the randomO system function. 

10.3.4 Break and Continue 

Vera provides the break and continue statements for use inside randseq blocks. 

10.3.4.1 Break r.-.-.&z v- v-$b/ > 5 

The break statement is used to terminate a randseq block. The syntax to declare a break statement is: 
break; 

A break statement can be executed from a code block within a production definition. When a break 
statement is executed, the randseq block terminates immediately and control is passed to the first line of 
code after the randseq block. * • * ' 

This is an example of a production definition using a break statement: 

SET0P_COUNTER: { 

integer regis = regFile.getRegisterO ; c 
integer value Aroi; l/v;i .-.^. tin . ;r:r: , . i-.^.-.l ,r- " tv --.,, 

nes tingLievel*+ ; ^ 
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if (nestingLevel == MAX_NESTING) break; 



} 



This example executes the break if the conditional is satisfied. When the break is executed, control 
passes to the first line of code after the randseq block. 



The continue statement is used to interrupt the execution of the current production. The execution con- 
tinues on the next item in the production from which the call is made. The syntax to declare a continue 
statement is: 



The continue statement passes control to the next production item in the production from which the call 
is made without executing any code in between. 

This is an example of a production definition using a continue statement: 

LOOP_BLOCK: SETUP — COUNTER GEN_LABEL; 

SETUP_COUNTER: { 

integer regis = regFile.getRegister ( ) ; 
integer value = ADDI; 
nestingLevel++; 

if (nestingLevel == MAX_NE STING) continue; 

} ; 

This example first executes the SETUP JCOUNTER production definition. When the continue is execut- 
ed, the code after the continue is ignored and control passes to the GENJABEL production definition. 



Value passing within randseq blocks allows you to associate a d^ua type with each production definition 
in order to pass values between production definitions. There are two components of value passing 



10.3.4.2 Continue 



continue; 



10.4 Value Passing 



within randseq blocks: value declaration and value passing functions. 



10.4.1 Value Declaration 



To associate a data type and value^with a given non-terminal production, you must declare the produc- 
tion using the prod declaration. The syntax to declare a production for value passing is: 



prod datatype product ion^name; 




datajype - The daiajypc integer, bit, string, enumerated type, or any object ^ * 
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production _name - The productionjname is the name of the production that is passing the value. 

Multiple productions can be declared in a single declaration statement, similar to variables. Vera per- 
forms strict type checking for passing values. 

10.4.2 Value Passing Functions 

Vera provides two functions used to pass values in randseq blocks: prodsetO and prodgetO. The prod- 
setO and prodgetO system functions can be called from Vera code blocks within production definitions. 

prodsetO 

The prodsetO system task is used to set a value associated with a non-terminal. The syntax to set a val- 
ue is: 

prodset (value t, productionjname [, occiirrence_numberl ]); 

value - The value is the value you want to pass. It must be of the same type as the prod declaration. It 
can be an integer, bit, string, enumerated type, or object 

productionjname - The productionjname optionally specifies the name of the non-terminal production 
the value is being assigned to. If it is omitted, the production that the task is called in is assumed to 
be the production to the left of the colon (:). 

occurrence jnumber - The occurrencejiumber optionally specifies which occurrence of the same 

production name receives the value. If the same production is referred to multiple times in the same 
definition, the first is 1, and the others are numbered sequentially. If it is omitted, it is assumed to 
bel. 

The prodsetO system task assigns the specified value to the specified occurrence of the non-terminal 
production. This value can be retrieved using the prodgetO system function. 

prodgetO ' ' " ' ~ ' ' 

The prodgetO system function is used to retrieve values assigned to non-terminal productions. The syn- 
tax to pass a value is: 

prodget ( {productionjname I , occurrence_number} ] ) ; 

productionjname - Hie productionjname specifies the name of the non-terminal production die value 
has been assigned to. If it is omitted, the production that the task is called in is assumed to be the 
production to the left of the colon (:). 

occurrence _number - The occurrencejnumber optionally specifies which occurrence of the same 

production name receives the value. If the same production is referred to multiple times in the same 
definition, the first is 1, and the others are numbered sequentially. If it is omitted, it is assumed to 
be 1. 

The prodgetO system function returns the value assigned to the specified non-terminal production. 



214 Chapter 1 0. Vera Stream Generator 



Vera 4.0 User's Manual 



Production values can only be associated with production names to the left of the code block where 
prodsetO is called. If you assign a value to the production name to the left of the colon (:), the value is 
passed up to the calling production, where it can be retrieved. 

Calling prodgetO on a production entry that has not been assigned returns an undefined value. 
You cannot set a value for a production that has not yet been executed. For example: 

main : prod_a {prodset <5,prodLb, 1) ; } pro<3Lb /* invalid! */ 

main : prodLa {prodset (prod^a, 2) ; } prodjs procLa /* invalid! */ 
main : prod_a {integer tmp = prodget (procLa) ; 

prodset (tmp+5 ,prod_a) ; } prod_b /* valid! */ 

This is an example of how to pass values within a randseq block: 

program GenList 
{ 

list vsgList; 
randseq () 
{ 

prod list_node ELEMENT; 

TOP : { vsgList = new; } LIST END 
? 

LIST : &(10) LIST ELEMENT 
{ 

list_node lnode = prodget ( ELEMENT, 1 ) ; 

vsgList. insert ( lnode ); 

printf Clast insert %0d\n - , lnode. data); 

} 

| ELEMENT 
{ 

list_node lnode = prodget ( ELEMENT, 1 ) ; uv 
...vsgList .insert ( lnode ); 
printf ("inserting %0d \n m , lnode - data) ; 

} 

; 

ELEMENT . : { 

listjiode lnode = new; 
prodset ( lnode ) ; 

printf Cnew node is created %0d\n* # lnode. da ta ) ; 

> 

; .... t ' * ' 

END : { vsgList. printAllO ; } . . .. 
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This example defines the list object vsgList. When the randseq block is entered, the TOP production is 
executed. First, a list object is instantiated. Then the LIST production is executed. The LIST production 
consists of a weighted LIST ELEMENT production and an ELEMENT production. If the LIST ELE- 
MENT production is selected, the LIST production is called recursively and the ELEMENT production 
is postponed. The original selection between ELEMENT and LIST ELEMENT is then made again. The 
cycle continues until the ELEMENT production is selected. At that time, Inode is assigned a value via 
the prodset call in the ELEMENT production. That value is inserted into vsgList via the insert call in 
the code block. Finally, the previously unexecuted ELEMENT calls that had been postponed when 
LIST ELEMENT was selected are executed. Control is then passed back to the TOP production, which 
executes the END production. 

Note that each production is not assigned a single value. Instead, a stack of values can be assigned to a 
production, which are retrieved, in order, through the dynamic execution of the production set. 
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Example 5: Vera Stream Generator 

This is an example using the Vera stream generator. The example includes these features: 

• Random sequence blocks 

• Productions 

• Value passing 

This example includes these files: 

• globaldef.h 
Q • memCtl.if.vrh 
^ • vsg.vr 

2i * RUN (a run script) 

y] 

f j The RUN script generates a header file for vsg.vr. 

% Files included in the distribution but not shown here include: 

yj • coverage.vrh 

= • stimgen.vrg 

JS3S. 

e : 
v ~ 

J= globaldef.h 

« lifndef FILE_GLOBALDEF_H 

Zl # define F I LE_GLOB ALDEF_H 

enum MEH_SEG = MEM^SEGO, MEM_SEG1, MEH_SEG2; 

enum COVERAGE.VAL_OPT = GENERIC.COV, STATE_C0V, TOANS_COV; 

♦define W_NOOP 1 
tdefine W_FLUSH_CACHE 2 
♦define W_BURST_READ 8 
♦define W_SINGLE_R£AD 4 
♦define W_BURST_WRITE 7 
♦define W_S INGLE_WRITE 3 

♦endif 
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memCtl.if.vrh 

fifndef INC_MEMCTL_IF_VRH 
# define INC_MEMCTL_IF_VRH 
# define INPUT_EDGE PS AMPLE 
#define OUTPUT_EDGE PHOLD 
fdefine OUTPDT_SKEW #1 

interface memCtl. 
{ 

input [3:0] mc_state INPUT_EDGE ; 

inout [2:0] cmd INPUT_EDGE OUTPUT_EDGE OUTPUT.SKEW ; 
inout cache_hit INPUT_EDGE OUTPUT_EDGE OUTPUT_SKEW ; 
inout cache_dirty INPUT_EDGE OUTPUT_EDGE OUTPUT_SKEW ; 
input elk CLOCK ; 
} // end of interface memCtl 

port mport 
{ 

mc_state; 
cmd; 

cache_hit ; 
cache_dirty; 
}//end mport 

bind mport mbind 
{ 

mc_state memCtl .mc_state; 
cmd memCtl . cmd; 
cache_hit memCtl . cache_hi t ; 
cache_dirty memCtl . cache_dirty ; 
}//end bind- 

#endif 



vsg.vr 

# inc lude <vera_de fines . vrh> 

finclude 'RTL/memCtl .vh* 

# include "memCtl.if.vrh - 

finclude 'globaldef .h* 

finclude •stimgen.vrh" 

finclude •coverage.vrh" 
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extern t_MemCtl_Cov MemCtl_Cov; //coverage obj 
extern t_CmdPacket CmdPacket; //command packet object 
extern event evt_new_cmd; //global event variable, signalling new 

//command is generated 

// task genera testes t: 

// uses randseqO as a sequence generator to create 

// randomized sequence of commands out of the 6 command 

// NOOP, FLUSH_CACHE. BURST_READ, BURST_WRITE f SINGLE_READ, 

// SINGLE_WRITE. Environment conditions such as memory addresses 

// and cache-hit status are generated during the sequence also. 

// The productions are designed such that it will keep 

// generating commands until coverage-goal is met by 

// doing a query (GOAL) after each command 

task generate_test with mport () 
{ 

integer f _cnt ; 

rands eq ( ) 

{ 

prod integer FLUSH_A_LINE; 
STREAM : TRANSACTION 

<if ( !MemCtl_Cov. query (GOAL )) STREAM > 
TRANSACTION : GEN_ADDR SEL_CMD 
{ 

trigger ( ONE_BLAST, evt_new_cmd ) ; 

} 

GEN_ADDR : 
{ 

randcase 

{ • , ^ 

1 : CmdPacket. gen_addr ( MEM^SEGO ) ; 

1-: CmdPacket. gen_addr ( KEM_SEG1 ); 

1 : CmdPacket. gen_addr ( MEH_SEG2 ); 

) 

) .. '.. .. 

i 

SEL_CKD : & ( W_NOOP ) DOJNOOP 

| & ( W_FLUSH_CACHE ) {f_cnt = 0; } DO_FLUSH_CACHE 

| & ( W_BURST_READ ) DO_BORST_READ 

| & ( W_SINGLE_READ ) DO_SINGLE_READ 

I 6 ( W BURST JWRITE ) DO_BORST_WRITE 

| & ( W SINGLE_WRITE ) DO_SINGLE_WRITE 
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01 

yj 




D0_N00P : 
{ 

QndPacket . exec_cmd with (get_bind()) 
( N0__0P ) ; 

} 

DO_FLUSH__CACHE : FLUSH_A_LINE 

< if ( prodget ( FLUSH_A_LINE ) < 31 ) DO_FLUSH_CACHE > 



FLUSH_A_LINE : 
{ 

CmdPacket . exec_cmd with ( get_bind() ) 
( FLUSH_CACHE ) ; 
CmdPacket . incre_addr ( ) ; 
prodset ( f_cnt++ ); 

} 

2 

DO_BURST_READ : 
{ 

integer wait_time; 

CmdPacket . exec_cmd with ( get_bind() ) 
( BURST_READ ) ; 

if ( CmdPacket .stim_cache_hit ) 

wait_time = 4 ; 
else if ( CmdPacket . stim_cache_dirty ) 

wait_time = 6 ; 
else 

wait_time = 5; 
repeat ( wait_time ) 8 (posedge CLOCK) ; 



} 



DO. 



.S XNGLE_READ 



{ 



integer wait_time; 

CmdPacket . exec_cmd with ( get_bind() ) 
( SINGLELREAD ) ; 
if ( CmdPacket. stim_cache_hit ) 



wait_time = 1 ; 
else if ( CmdPacket. stim_cache_dirty ) 



wait_time = 3 ; 
Glee 



} 
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DO_BURST_WRITE : 
{ 

integer wait_time; 

CmdPacket . exec_cmd with ( get_bind() ) 
( BUR£T_WRITE ) ; 
if ( CmdPacket. stim__cache_hit ) 

wait_time = 4 ; 
else if ( CmdPacket. st im_cache_dirty ) 

wait_time = 6 ; 
else 

wait_time = 5; 
repeat ( wait_time ) 6 (posedge CLOCK) ; 

} 
§ 

DO_S INGLE_WRITE : 
{ 

integer wait_time; . 

CmdPacket . exec_cmd with ( get_bind() ) 

( SINGLE_WRITE ) ; 

if ( CmdPacket. stim_cache_hit ) 

wait_time = 1 ; 
else if ( CmdPacket. stim_cache_dirty ) 

wait_time = 3 ; 
else 

wait_time = 2; 
repeat ( wait_time ) G (posedge CLOCK) ; 

) 

} //end rands eq 
)//end task 

RUN 

#!/bin/csh -f 

rm -f *.vro core *.vshell >& /dev/null 
vera -cmp -g -h vsg.vr 
if ($status) exit 1 
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11. Functional Coverage 

This chapter introduces Vera's functional coverage analysis and discusses how it is used. It in- 
cludes these sections: 

• Coverage Overview 

• Coverage Definitions 

• Instantiation and Triggering 

• Coverage Feedback: The Query Function 

• Coverage Administration 

• Cross Coverage 

• Backward Compatibility ' 

11.1 Coverage Overview ?r c; r 

As chip designs grow more complex and testing environments become increasingly sophisti- 
cated, emphasis is placed not only on testing the chip but testing it completely. With hundreds 
of possible states in a system and thousands of possible transitions, the completeness of tests 
needs to be a primary focus of any verification tool. 

Traditional coverage models use a code coverage methodology. They check that specific lines 
of code are executed at some point in the simulation. This method has inherent flaws. For in- 
stance, you can be certain that a device entered states 1, 2 and 3, but you cannot be certain that 
the device transitioned from state 1 to 2 to 3 in sequence. Even such a simple example displays 
the limitations of code coverage. With a sophisticated chip, such coverage is not adequate to 
ensure the integrity of the design. 

Vera supports a functional coverage system. This system is able to monitor all states and state 
transitions, as well as changes to variables. By setting up a nuinber of mordtor bins that corre- 
spond to states, transitions, and variable changes, Vera is able r to track the activity in the sim- 
ulation. 

Each time a user-specified activity occurs, a counter associated with the bin is incremented- If 
you establish a bin for each state, state transition, and variable change that you want to moni- 
tor, you can check the bin counter after the simulation to see how many activities occurred. 
Thus, it is simple to check the degree of completeness of the testbench and simulation. 
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Vera further expands this basic functionality to include two analysis mechanisms: open-loop 
analysis and closed-loop analysis. Open-loop analysis monitors the bins during the simulation 
and writes a report at the end summarizing the results. Closed-loop analysis monitors the bins 
during the simulation and checks for areas of sparse coverage. This information is then used 
to drive subsequent test generation to ensure satisfactory coverage levels. 

11.2 Coverage Definitions 

To check the coverage for a given simulation, you create coverage definitions. Fbr each cover- 
age definition, you must define the monitor bins, initialization routines, and any triggers or 
other synchronization mechanisms you want to use. Meanwhile, Vera assigns pre-defined 
properties and methods to the coverage objects that take care of the data collection and much 
of the analysis. In this way, Vera successfully encapsulates a large portion of the code into re- 
usable objects, which greatly facilitates their use. 

Coverage definitions behave very similarly to classes that exist within the object-oriented 
methodology. Like classes, coverage insJaJnC^Shave definitions. However, unlike a class defi- 
nition, coverage definitions cannot contain methods and variables. Instead, they contain c/cc/a 
rorf/onS of monitor bins. ' ; ^r.;;- 'NXv t. rT 

Because coverage definitions behave very similar to classes within the object oriented method- 
ology, they can be used in a similar manner. For instance, if you have four copies of .the same 
bus protocol, you can instantiate four instances of the same coverage, definition without creat- 
ing four separate coverage definitions. When you call the coverage object, within a. Vera task, it 
inherits the virtual port to which the task is bound. So the same coverage definition can be 
used to check multiple ports or signals. *' ' : ' 

The basic syntax for defining a coverage definition is: 

coverage_d«f Object^name (state_ variable, arguments) { 

coverage declarations; - , ' 
.measure of coverage; 

coverage goal; ' " r * ' ; '* 

' ' ' coverage option; " *"'■'" " ! ' ■ " : - 

• : * - " '' initialization; ' ' V " - ' ; ' ■ ~ fil - <<■- - 



statejoariable - The statejoariable is the type and variable name being monitored by the 
coverage definition. It can be of the following types: integer, bit field (in the form 
bit[nl:0]), enumerated type, and port 

The state variable can be used as a parameter throughout the coverage definition. 
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arguments - The arguments are initialization parameters passed at instantiation. They have the 
same conventions as subroutine arguments and can have their default values set within 
the declaration. Arguments must be of the following types: integer, bit field, enumerated 
type and port variable. 

The details of the remainder of the coverage definition are explained in subsequent sections. 



Note - The coverage definition is just a definition. It does not 
instantiate a coverage object To instantiate a coverage object, see 
Section 113, Instantiation and Triggering." 



1 1 .2.1 Expressions within Coverage Definitions 

Expressions within coverage definitions are used for specifying coverage declarations, mea- 
sure of coverages, and coverage goals. These expressions are a subset of the general Vera ex- 
pressions. Expressions must be one of the following data types: integer, bit, enum, port_var or 
interface signaLThey cannot include arrays, the =, ++, or - operator, or function calls other 
than queryO, get_cycleO, and get_time0. Function calls are only allowed in if expressions and 
coveragejoalue expressions. Expressions within coverage objects can reference global variables 
and arguments passed into the coverage definition. 

11.2.2 Coverage Declarations 

Coverage declarations are used to declare legal states, illegal states, legal transitions, and ille- 
gal transitions. They associate bins with these activities and monitor how many times these ac- 
tivities occur within a simulation. 

11:2.2.1 State Declarations 

The syntax for a state declaration is: 

state et&tejbin^name istate_speci£ication) conditionals , 

State Specification 

In a state declaration, a single state or multiple states are associated, with a monitor bin via a 
state specification. The state specification is a list of elements (separated by commas) that are 
matched against the current value of the state variable For the current cycle, any matches in- 
crement the bin counter by one. 

Each element of the state specification must be in one of the following formats: 

"'*.*" ■ ' * ■■ • ■ ■ " \ ~ 

1. expression- A counter is added to the bin when the state variable matches 

the expression exactly. V or V must match exactly. 

Synopsyslnc. ? 



226 Chapter 1 1 . Functional Coverage Vera 4.0 User's Manual 



2. lowihigh - A counter is added to the bin when the state variable matches 

any value in the range from low to high. 

3. low:high:$tepxepeat - This creates multiple ranges. The first block ranges from low to 

high. The second block ranges from (high+step) to (2*high- 
low+step). New blocks are generated repeat times. For example: 
2:5:10:3 would produce states {2, 3, 4, 5, 15, 16, 17, 18,28,29,30,31} 
(2,3,4*5) -> (15,16,17,18) -> (28,29,30,31) 

Complex state specifications can be generated by separating multiple formats with commas. 
For example: 

state statejbxn_name (8 'bOOOO_01XX, 8:10, 15:17:7:2) 

This state specification will increment the bin counter if any of the specifications matches the 
state variable. In this example, a counter will be added to the bin if: 

(i) the state variable matches STjOOOO.OIXX exactly 

(ii) the state variable falls in the range of 8 to 10 

(iii) the state variable falls in the range of 15 to 17 or 24 to 27 



Note - V and V are not allowed in repeated range statements. 



A special case of a state declaration uses the all state specification, 
state state_bin_name (all); 

This statement indicates that all values of the state variable increment the specified bin 
counter. 



Note - If you use state(all), a significant amount of memory is used if 
the number of sampled and unique states is large. 

It is important to note that state specifications are evaluated only once, at the time the cover- 
age object is instantiated. While the state variable is being monitored, the state specification re- 
mains constant 

State Bin Names 

Bins can be assigned explicit names, or the Vera compiler can generate implicit names. The 
Vera compiler generates implicit bin names based on the state specification. The general for- 
mat is always prefaced by 6_. The following characters are converted to underscores (_) : coxn * 
ma 0)/ colon (:), slash (/), dash (-), plus (+), asterisk (*), and period (.). The following 
characters are ignored when the bin name is generated: double quote (*), brackets ft])/ paren- 
theses ( 0 )/ dollar sign ($), caret ( A ), backslash (\), and braces ({}). For example: 
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state expression 

(5,7,941) 
(15:37) 
(base*10+3) 
(all) 



implicit bin name 

s_5_7_9_ll 

s_15_37 

s_base_10_3 

s.all 



Conditionals 

You can add conditional statements at the end of any state declaration. Conditional statements 
can be any valid Vera conditional statement. Functions other than get.cydeO and get.timeO 
cannot be called in the conditional. If there is a conditional statement attached to the state dec- 
laration, the bin counter will be incremented only if both the condition is true and the state 
variable matches the state specification at the same time. For example: 

state jmp.ins ( 8 'b0000_01XX, 8:10, 15:17:7:2) if (test ON) ; 

This state declaration creates the bin jmp_ins . The bin counter is incremented when the 
state variable matches the specification AND the conditional is true. 

Multiple State Bin Declarations 

A state declaration can have multiple bins declared on a single line as follows: 

state bO (0), bl (1) , b2 (2); 

In this example, bO, bl, and b2 are separate states, each with its own state specification. 

Further, multiple state declarations are allowed, and the same state can be associated with 
multiple bins. For example: 

state bO (0:10) ; 
state bl (10:20) ; 

In this example, state 10 is associated with both bin bO and bin bl. 
m_state 

The m.state state declaration is used to declare multiple state bins up to a maximum of 4096 
bins. The syntax is: , r4 t . 

upstate s tat e_bin_jiame (expl:exp2); 

statejbinjname - The staiejnnjname is the base name of the state bins being created. 

exp - The exps can be any valid coverage expression. You cannot call functions in the 
expressions. The expressions can include variables. 

When the m_state declaration is used, multiple state bins are created, covering aU the values 
in the range. The expressions are evaluated when the coverage object is instantiated.. For ex- 
ample: 
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ro_state si (2:4); 
This example creates these bins with their respective state values: 

state bin name state value 

sl_0000 2 

slJMOl 3 

sl_0002 4 

If no bin name is specified, the same example yields these bin names and values: 

state bin name state value 

s.0002 2 

sj)003 3 

s_0004 4 

11.2.2.2 Illegal State Declarations 

Illegal state declarations associate illegal states with a monitor bin. The syntax is: 
bad_Btate error_bin_name (state^specification) conditional; 

Illegal or bad states are those states in the design that, when entered, result in verification er- 
rors. - 

The state specification can be any expression or combination of expressions as in the state dec- 
larations. However, it is often useful to define every state that is not in the state declarations 
as a bad state. To use that definition of bad states, you can use the not state specification: 

bad_«tate error__bin_name (not state) ; 

This statement increments the specified bin counter every time the state variable matches a 
value not defined in the state declarations. If you do not specify an error bin name, the implic- 
it name is s_not_state. 

If you want to specify multiple bad states, you can use the m_bad_state declaration. The syn- 
tax is: " * : * ■: . •■• <, , . . J-f 

. s*_bad_«tate error_bin_name {expliexp2) ; 

When the m_bad_state declaration is used, a bin for each value in the range is created. If no 
bin name is specified, the same naming conventions for m_state are used. 

11.2.2.3 Transition Declarations 

Transition declarations associate state transitions with monitor bins. The syntax for transition 
declarations is: 

trana trans^bin^name (state_ transitions) conditional: 

— 4P* ' 
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State Transition 

State transitions are specified by declaring a sequence of transitions between states. The gener- 
al format is: 

trans trans_bixx_name <state_set_l -> state_set_2 -> ... -> s ta te.se t_N) ; 

A state set it made up of one or more transition states. Transition states can be any of the fol- 
lowing: 

1. a state bin, specified in a state declaration 

2. any of the state specifiers available in a state declaration . 

3. a Perl regular expression matching a state bin name, enclosed in double quotes 

If multiple transition states make up a single state set, they must be enclosed by brackets ([]) 
and separated by commas. For example: 

tranf trans_bin_name <[jms_ins, br:xor, * jmp[0-9]+'] -> [15:20:2:100]); 

This example defines a complex state transition. The specified bin counter is incremented 
when any of the following occurs: 

(i) the state variable dianges from a state defined in the jms_ins state declaration to a state 
that falls in the repeated range defined by [15:20:2:100] 

(ii) the state variable changes from a value in the range from br to xor to a state that falls in the 
repeated range defined by [15:20:2:100] 

(iii) the state variable changes from a state defined in any state bin that begins with "jmp" and 
ends with at least one digit to a state that falls in the repeated range defined by [15:20:2:100] 

A special case for transition states is the all state transition argument. 

tr«M trans_birx__name (all) ; 

The specified bin counter is incremented on any state variable transitions. 

Note - If you use trans(all) / a significant amount of memory is used if 
the number of sampled and unique transitions is large. : - 1 



Transition Bin Names 

Bins can be assigned explicit names, or the Vera compiler can generate implicit names- The 
Vera compiler generates implicit bin names based on the state transition. The general format is 
always prefaced by t_. The following characters are converted to underscores (J: comma (,), 
colon (:), slash (/), dash (-), plus (+), asterisk (*), and period (.). The following characters are 
ignored when the bin name is generated: double quote ("), brackets (U), angled brackets (o), 
parentheses ( 0 ), dollar sign ($), caret ( A ), backslash (\), and braces <{}). For example: 




Synopsys Inc. 



230 Chapter 1 1 . Functional Coverage Vera 4.0 User's Manual 



transition expression 
(5 -> 7 -> 9 -> 11) 
(15:37 -> 25) 

([base»10, 9] -> "jmpl0-9]+") 
(all) 



implicit bin name 

t_5_7_9_ll 

t_15_37_2_5 

t_base_10__9JmpO_9_ 

t.all 



Conditional 

You can add conditional statements at the end of any transition declaration. Conditional state- 
ments can be any valid Vera conditional statement Functions other than get_cycleO and 
get.timeO cannot be called in the conditional. If there is a conditional statement attached to 
the transition declaration, the bin counter will be incremented only if both the condition is 
true and the state variable makes the specified transition at the same time. For example: 

trans jmp_ins (8:10 -> 15:17:7:2) if (test == ON) ; 

This transition declaration creates the bin jmp_ins . The bin counter is incremented when 
the state variable makes the specified transition AND the conditional is true. If you specify a 
sequence of transitions, the conditional is only evaluated during the final transition. 

Multiple Transition Bin Declarations 

A transition declaration can have multiple bins declared on a single line as follows: 
trans bO (0 -> 1), bl (1 -> 2), b2 (2 -> 3); 

In this example, bO, bl, and b2 are separate transitions, each with its own transition specifica- 
tion. 

A special case of a transition declaration uses the all transition specification. 

trans transjbinjname (all) ; 
This statement indicates that all transitions increment the specified bin counter. 

m_trans 

The m.trans transition declaration is used to declare multiple transition bins up to a maxi- 
mum of 4096 bins. The syntax is: 

8L.trans trans_bin_name (expl : exp2 -> exp J : exp4 ) ; 

transjbinjname - The transjbinjname is the base name of the. transition bins being created. 

exp - The exps can be any valid coverage expression. You cannot call functions in the 
expressions. The expressions can include variables. 

When the m.trans declaration is used, multiple transition bins are created, covering all the 
transitions in the specified ranges. Each set of expressions specifies a range. A bin is created 
for each permutation of valid states. For example: 

Synbpsy^nc. 
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m_trans tl (2:3 -> 4:5); 

This example creates these bins with their respective transitions: 

transition bin name transition 

tl_0000_0000 2 to 4 

tl_0000_0001 2 to 5 

tlJWOljOOOO 3 to 4 

tl_0001_0001 3 to 5 

In this example, states 2 and 3 are given the identifiers 0000 and 0001, and states 4 and 5 are 
given the identifiers 0000 and 0001. These identifiers are used in the transition bin's implicit 
name. If other states are added to either side of the transition, they are assigned identifiers in 
sequential order (i.e., the next state is 0002, and so on). 

If no bin name is specified, the same example yields these bin names and values: 

transition bin name transition 

t_0000 JXJ00 2 to 4 

t_0000 JXWl 2 to 5 

t_0001_0000 3 to 4 

t.0001.0001 3 to 5 

11.2.2.4 Illegal Transition Declarations 

Illegal transition declarations associate an illegal transition with a monitor bin. The syntax is: 

bad_trana trans_bia_name (state_ transit ions) conditional; 

The state transition can be any state transition set valid for transition declarations. However, it 
is often useful to monitor all transitions that have not been defined as legal transitions. For 
such instances, Vera uses the not trans argument 

bad.traa* trans_bin_name (not trmum) ; _ ( .. 

The counter associated with the specified bin will be incremented every time a transition oc- 
curs that is not explicitly defined in the transition declaration. If you do not specify the bin 
name, the implicit name is t_not^trans. 

The not trans modifier applies only to single transitions between two state sets. It does not ap- 
ply to sequences of transitions- So, if you use not trans and you specify a sequence of transi- 
tions (A -> B -> Q, you must also specify each valid transition within the sequence (A -> B, B 
->Q- 

If you want to specify multiple bad transitions, ypu can use the m_bad_trans declaration. The 
syntax is: 

• aJb+6JLT*xxm Grror^pin^name {explzexp2 -> ejgp3iexp4); 
Synopsys Inc 



232 Chapter 11. Functional Coverage 



Vera 4.0 User's Manual 



When the m_bad_trans declaration is used, a bin for each transition is created. If no bin name 
is specified, the same naming conventions for m_trans are used. 

11.2.2.5 Coverage Declaration Example 

state s_IDLE ( IDLE ), 8_FLUSH_C( FLUSH_C ), S_LOAD_C ( LOAD_C ); 
state S_B_RD ( B_RD0:B_RD3 ) , S_B_WR ( B_WR0:B_WR3 ); 

state s_all_RD ( S_RD, B_RD0 : B_RD3 ), s_all_WR ( S_WR, B_WR0:B_WR3 ); 
bad_state ( not state ); 

trans t_JToop ( IDLE -> IDLE ) if ( mbind. $cmd === N0_0P) ; 

trans t_CacheMissDirty ( IDLE -> •s_FLUSH_C" -> L0AD_C -> START ) 
if ( mbind. $cmd !== NO_OP && mbind. $cmd !== FLUSH_CACHE 
&& mbind. $cache_hit === 0 && mbind. $cache_dirty === 1 ); 

trans t_SingleRead (START -> S_RD) if (mbind. $cmd === SINGLE_READ ); 

trans t_SingleWrite (START -> S_WR) if (mbind. $cmd === SINGLE_WRITE) ; 

trans t_Burst Write (START -> B_WR0 -> B_WR1 -> B_WR2 -> B_WR3) 
if (mbind. $cmd === BURST_WRITE) ; 

This example is a small piece of a complete coverage declaration. This example declares many 
valid states under various bin names. It also declares several valid transitions. Each time one 
of the defined activities occurs, the counter to the corresponding monitor bin is incremented 
by one. 

11.2.3 Measure of Coverage 

The measure of coverage defines how coverage is specified. The default setting for the mea- 
sure of coverage computes the percentage of monitor bins that have a non-zero count The 
measure of coverage is recomputed each time query(GOAL) is called or each time a coverage 
report is generated. 

You can explicidy define the measure of coverage. The syntax is: 

coverage_v*l = 100* query (command, 'bin! type, m bin__pattern m / operand, hit) 
I query {command, binl:type t *bin_pattern m ) ; 

command - Command determines the type of results you are going to query. It can be either 
NUM_BIN or SUM. Use NUM.BIN to count the number of selected bins. Use SUM to 
calculate the sum of counter values on the selected bins. 

bin_type - The binjtype specifies the bin types you want to select from. The bin types are 
STATE, TRANS, BAD_STATE, and B ADJTRANS. To select more than one type of bin, 
use the 'or' operator ( I ). 

bin_pattern - The bin_pattern variable is matched against the bin names of the specified type. 
Only those bins whose names contain the bin_pdttem are included in the query. For 
example, if bin_pattern is "bus", all bins with ''bus" in their names will be included. If you 

— - ^ftr 
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want to select all bins whose names begin with a specific string, insert a caret ( A ) before 
the string (e.g. " A bus"). To select all bins of the specified type regardless of name, use 
as the bin_pattern. 

operand - The operand must be one of the following: greater than (GT), greater than or equal to 
(GE), less than (LT), less than or equal to (LE), equal to (EQ), or not equal to (NE). 

hit - The hit specifies the number of counter hits to which the query is compared using the 
operand. It can be any non-negative integer. 

The measure of coverage calculates your current coverage. Put simply, it is a ratio of the num- 
ber of states that have been "hit" to the total number of valid states. 

Using these definitions, you can explicitly define the measure of coverage. For example, to de- 
termine the percentage of STATE and TRANS bins with at least one counter hit, use: 

coverage.val = 100 * query (NUH.B IK, TRANS | STATE, *.**, GT, 0) / 
query (NUM_B IN, TRANS | STATE , V*'); 

This example is the default measure of coverage. 

1 1 .2.4 Coverage Goal 

The syntax to set the coverage goal is: * - : , 

eovarage goal = expression; 

expression - The expression can be any valid coverage block expression. 

The coverage goal is a percentage between 0 and 100. If there is no explidfly defined goal, the 
default is 90. The coverage goal should be set such that when it is reached, all coverage objec- 
tives have been met 

The coverage goal is most often used with the queryO system function, discussed in 
Section 11.4. 

11.2.5 Coverage Options 

The syntax to set the coverage option is: 

coveraff«_option = option; ; 

option - The options are HI, which specifies that this object will be used for cross-correlation 
and needs a time stamp, LO, which specifies that only counter information must be 
retained, or CROSS_TRANS, which includes transition events in a cross coverage report. 

Multiple options can be selected using a + or I to separate options. The default setting is LO. 
If both HI and LO are chosen, the option is HI. Because the CROSS_TRANS option is used 
for cross correlation, it can only be used with the HI coverage option. 
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The CROSSJTRANS modifier includes transition events in a cross coverage report. By de- 
fault, cross coverage reports include only state information. If the CROSSJTRANS modifier is 
active, the cross coverage report contains both state and transition information. In this way; 
you can include information on transitions that occur when specified states are in use. Howev- 
er, transition/ transition associations are not included in the cross coverage report 



Note - If CROSSJTRANS is active, it must be active for every 
coverage block in the coverage report If it is not, a warning message is 
issued and the cross coverage report is not generated. 



11.2.6 Initialization 

Coverage definitions are initialized by an embedded case block that is invoked only when the 
definition is instantiated. The outer level of the case block resembles a standard Vera case 
statement except that it can also include the full range of coverage statements. The initializa- 
tion case block can contain any of these elements: 

• coverage declarations (state, bad state, transition, and bad transition 
declarations) 

• measure of coverage 

• coverage goal 

• other case blocks 

The syntax for an initialization sequence generally follows this format. 

case (initialization_j>aramater) 
{ 

expressi onl : s ta temen tl ; 
expression2 : sta tement2 ; 

default: 

> 

Initialization sequences are generally used to conditionalize coverage statements so that the 
coverage definition is more specialized upon instantiation. For example, an initialization se- 
quence can be particularly useful when passing flags as arguments when the coverage defini- 
tion is instantiated. For instance, if state_flag is defined such that false turns on bad states and 
true turns off bad states, the following syntax would be used: 

case (state_£lag) . ^ 
{ 

0: bacLstate bacLstJbin (0, 2, 3); 
default: 

) "* - 
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This example declares states 0, 2, and 3 as bad states if the flag is set. Each time this coverage 
definition is instantiated, the flag will be checked. This enables you to define one coverage 
definition, but use it in different ways throughout the simulation. 

11.3 Instantiation and Triggering 

Coverage definitions are not created until they are instantiated using the newcov command. 
The syntax to instantiate a coverage definition is: 

coverage_de£inition instance_jiame = newcov (state_var. trigger. opt_args) ; 

coverage_definition - Coverage_definition is simply the name of the coverage definition that 
you are instantiating. 

instance_name - The instancejname is the name of this instance of the coverage definition. 
Remember that newcovO can be used to create multiple instances of the same definition. 

statejoar - The state joar is the value that is monitored by the coverage definition. It is the 
state variable or expression for which the coverage definition has been created. 

trigger - The trigger is a trigger expression that allows you to control when 

the object takes a sample. Coverage objects can be triggered on clock edges, variable 
changes, and sync events. 

opt_args - The optjirgs are the optional arguments. They must correspond to the coverage 
definition's optional arguments, if any exist 

The trigger can be used to sample on clock edges as per the synchronization command (see 
Section 4.4.1, -Synchronization*'). When the specified clock edge occurs, the object is triggered. 

The trigger can also be used to take samples only on changes to variables using the 
wait_var construct see Section 6.1.1.2, "wait_var0"). When a variable change occurs, the object 
is triggered. 

Coverage objects can also be triggered on sync events (see Section 6^2, "Sync"). When the 
sync is unblocked the object is triggered. 

There are a few things to note when using triggers. First, to eliminate race problems, if the 
trigger involves clock delays, the coverage object is invoked at the end of the simulation cycle 
after all Vera processing that can change variables is complete. Second, if the sample occurs on 
every change, the coverage object is triggered at most once per simulation cycle even if the 
state variable changes multiple times. 

program memCtl_Test 

{ 

t_CmdPacket CmdPacket; 
t_MemCtl_Cov MemCtl_Cov; 
t_Cm4_Cov CndLCov; 

event evt_new_cmd; — — ^ftr 
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// instantiates global objs 
reset_mc with mbind ( ) ; 
fork 

{state_snooper with xnbindO;} 
{ cmd_snooper ( ) ; } 
join none 

// Test with GENERIC_COV value 
CmdPacket = new; 

CmdPacket . command = NO_OP; // just to initialize before coverage begins 
MemCtl_Cov=newcov(mbind.$mc_state,e(posedge CLOCK) # HI, 100, 
GENERIC_COV ); 

Cmd_Cov=newcov (CmdPacket. command, sync ( ALL, evt_new_cmd ) ) ; 
print f (•##### GENERATE SEQUENCE FOR GENERIC COVERAGE #####\n\n'); 
genera te_t est with mbind ( ) ; 

coverage ( CROSS , MemCtl_Cov, CmcLCov, • generic . rpt • ); 
}//end program 



$cmd = NO_OP async; 

62 $mc_state == IDLE; }//end reset_mc 

task state_snooper with mport () 

* { 

string s_str; 
while (1) 



0 (posedge CLOCK) ; 
case ( $mc_state ) 
{ 

4'dO : S_Str = -IDLE*; 
4'dl : s_str = -START"; 
4'd2 : s_str = -FLUSH_C; 
default : s_str = ■ UNKNOWN_STATE • ; 
)//end case 

if ( $mc_state === 4*d0. ) printf {•\n m ); 
printf {• %s -> •» s_str); 
)//end while 
)//end task state_snooper 

task cmdLsnooper ( ) 
{ 

string c_str; 
while (1) 
{ 

sync (ALL, evt^new_cmd ) ; . ./ 



task reset_mc with mport ( ) { 



{ 
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case ( CmdPacket . command ) 
{ 

3'dO : c_str = •NO_OP"; 

3'dl : c_str = ■BURST_R£AD" ; 

3'd2 : c_str = "BURST_WRITE" ; 

3'd3 : c_str = -SmGLE^READ" ; 

default: error ("Unknown Command %0d\n", CmdPacket. command) ; 



printf C ## CMD : %s ## c_str ); 
delay ( 2 ) ; 
)//end while 
}//end cmd_snooper; 

This example forks off two processes, each of which calls one of the user-defined tasks. The 
cmd_snooper ( ) task calls a sync, which triggers one of the coverage objects. The other cov- 
erage object is triggered on the positive clock edge. 

1 1 .4 Coverage Feedback: The Query Function 

There are a set of related, pre-defined methods associated with coverage objects that allow you 
to review the current coverage status. These are all integer functions with the name query. 
The query functions are in these forms: 



command - The basic form of query allows you to specify one of several commands: 

NUMJ5IN, SUM, FIRST, NEXT, GOAL and NAME. Each command returns a different 
value based on the binjype. 



query (command) ; 

query ( command, bin^type) ; 

query (command, bin_type, bin^pattern) ; 

query (command, Mistype, bin_pattern. operand, hit); 



Command 
NUM.BIN 
SUM 
FIRST 



NEXT 



GOAL 



Function 

Counts the number of bins of type binjype 

Sums die counters for all bins of type btnjype 

Returns the count of the first bin of type binjype (or -1 for 

failure) 

Returns the count of the next bin of type binjype in the 
sequence started with FIRST (or -1 if the sequence is com- 
plete) 

Returns a 1 if the coverage goal has been met (0 otherwise) 



Note - NEXT and GOAL can be used only in the single-argument 



form. 
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The single-argument form of the command applies to all bins. The additional arguments 
can be added to narrow the bin selection. 

binjtype - The binjype is any of the valid bin types: STATE, BAD_STATE, TRANS and 
B ADJTRANS. Multiple bin types can be specified using the 'or' operator ( I ). 

bitt^pattern - The bin ^pattern variable is matched against the bin names of the specified type. 
It can be any regular Perl expression. Only those bins whose names contain the bin_pattern 
are included in the query. For example, if binjpattern is "bus", all bins with "bus" in their 
names will be included. If you want to select all bins whose names begin with a specific 
string, insert a caret ( A ) before the string (e.g. " A bus"). To select all bins of the specified 
type regardless of name, use as the bin_pattern. 

operand - The operand must be one of the following: greater than (GT), greater than or equal to 
(GE), less than (LT), less than or equal to (LE), equal to (EQ), or not equal to (NE). 

hit - Hit specifies the number of counter hits to which the query is compared using the 
operand. It can be any non-negative integer. 

So, to compute the sum of the bin counts for state or transition bins with counts greater than 
10 each, we would have: 

query(SUM, STATE|TRANS, *.*', GT, 10); 
To continue a process until at least 10 bins has 10 or more hits, use: 

while (mycovobj .query (SUM, STATE|TRANS, % *', GT, 10) < 11) 
{-..} 

You can also set up loops that continue processes until the coverage goal is met: 

whi 1 e ( ! mycovobj . query ( GOAL ) ) 
(...) 

It is also possible to query the name of a monitor bin. The syntax is: 
qu«y_«tr (NAME) ; 

This function returns the monitor bin name in the FIRST/NEXT series (or null if the series is 
complete). ( 

Note - Outside of a coverage declaration we need to qualify query to 
get the appropriate method. For example, to get the query method for 
the cpO coverage object, we would use cpO .query. 



11 .5 Coverage Administration 

These coverage tasks provide adnunistrative control of coverage objects. The general format is: 
coverage (command £ , object_list} [ # - * filename'} ) ; . 

Synopsysjnc. 



Vera 4.0 User's Manual 



Chapter 1 1 . Functional Coverage 239 



command - The commands are: 



Command 


Function 


ON 


Turns coverage on (enables bin updating) 


OFF 


Turns coverage off (disables bin updating) 


CLEAR 


Clears all monitor bin counters 


SAVE 


Writes the bin data to the specified file 


LOAD 


Reads the bin data from the specified file 


REPORT 


Generates a coverage report 


CROSS 


Generates a cross-correlation report 



object Jist - The object Ji$t lists the coverage objects to be included in the execution of the 
command. If it is not included, all coverage objects will be included. 

filename - The filename specifies where the cross coverage report is saved. It is also used to 
specify the read and write files for the SAVE and LOAD commands. 

These commands allow you general control of coverage objects. They also allow you to do in- 
cremental coverage of your tests. At the beginning of a new test, you can LOAD the current 
coverage state, run the test to update the state, and then SAVE that state back to a file - to be 
updated again by a later test 

Note - You generally want to keep coverage turned off until after the 
circuit has been reset. 

The REPORT option generates a coverage report, detailing each bin and the number of hits it 
has taken. The CROSS report does a cross correlation between objects. Remember that the 
coverage option has to be set to HI for each selected coverage object to be correlated. 

When using SAVE/LOAD, coverage objects must be loaded in the same order as they were 
saved. In the "LOADING"' program, coverage definitions must also be instantiated in the 
same order as they were in the "SAVING" program. 

This is an example call for a coverage report 

coverage (REPORT, xnemCtl_cov, *memCtl . rpf ) ; 

This is the resultant coverage report 

Coverage Instance Name: MemCtl_Cov 
Coverage Instance Handle: 3 

Coverage Definition Name: t_MemCtl_Cov . 
Coverage Goal: 1 
Coverage Option: 1 
Measure of Coverage:- 1 

Coverage Sample Expression: < 
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State Name 


# defined values 


# hits 






s — START 


1 


125 






S_B_RD0 


1 


52 






S_B_RD1 


1 


52 






s_B_RD2 


. 1 


51 






s_B_RD3 


1 


52 






s_B_WR0 


1 


35 






S_B_WR1 




35 




.31 S. 

LJ 


S_B_WR2 




35 






s_B_WR3 




35 




01 


s_not_state 


0 


0 














™? " 

: : 


Transition Name 


# defined 


transitions 


# hits 




t_s_0_s_l 




1 


59 


S : 


t_s_0_s_3 ... 




1 


31 




t_s_3_s_l 




1 


66 


pi 


t_s_2_s_3 




1 


35 




t_s_0_s_2 




1 


610 




t_s_2_s_0 




1 


575 




t_s_10_s_ll 




1 


35 




t_s_ll_s_12 




1 


35 




t_not_trans 




0 


0 



11.6 Cross Coverage 

Cross coverage refers to the timestamping of events to ensure that specified events happen si- 
multaneously. For instance, a transition from state 1 to state 2 may not be sufficient for testing 
the device. You may need to know that a transition from state 1 to state 2 occurred while an- 
other state was active. 
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To use cross coverage, you must set the coverage option to HI. You can also optionally set the 
coverage option to CROSS.TRANS if you want to include transition information in a cross 



coverage report 



To invoke a cross coverage report, you must invoke the coverageO system function with the 
CROSS command: 

coverage (CROSS, object^list, "filename*); 

This is an example of a program using cross coverage: 

♦define OUT PUT_EDGE PRO 
idefine OUTPUT_SKEW #1 
# define INPUT_EDGE PSAMPLE 
tinclude <vera_def ines ,vrh> 
f include "counter . if .vrh" 

coverage_def cc_bitVec3 (bit [2:0] bitVec, integer cov_opt ) 



8 s tates : s_0 , — s_7 

7 trans : t_s_0_s_l t_s_6_s_7 and t_s_0_7_s_0 

1 bad^state : s_not_state 
1 bacLtrans : s_not_trans 
default coverage_val f coverage_goal 
cover age_opt ion = cov_opt 

V 

state (0). (1), (2), (3). (4). (5), (6), (7); 

trans t_s_0_s_l (0 -> 1), t_s_l_s_2 (1 -> 2) , t_s_2_s_3 (2 -> 3), 

t_s_3_s_4 (3 -> 4), t_s_4_s_5 (4 -> 5) , 

t_s_5_s_6 (5 -> 6), t_s_6_s_7 (6 -> 7) ; 
trans t_s_0_7_s_0 (0:7 -> 0); 
bad_state ( not state ) ; 
bacLtrans t_not_ trans ( not trans ) ; 

coverage_option = cov_opt; 
}//end cc_bitVec3 defn 

program counter_test 
{ // start of top block 
. ccjDitVec3 cc_cnth, cc_cnth2; 

string rptFileCrossSame = "crossCcSame-rpf ; 

// Start of counter_test 
reset_counter ( ) ; 

// start the high coverage , and clear their values 



.cnth=newcov ( counter . count . ©(counter .count async) , HI+CROSS_TRANS) ; 



{ 

/* 
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repeat (2) 6(posedge CLOCK); 

coverage ( CLEAR, cc_cnth, cc_cnth2 ) ; 

coverage ( CLEAR, cc_cnth2); 

repeat (2) 6 (posedge CLOCK) ; 

// OFF and ON with obj-list to be no arguments 

drive_counter ( 4 ) ; // all cov-counters up by 4 
drive_counter ( 5 ) ; 

// CROSS coverage report of the 2 virtually similar test 

coverage ( CROSS, cc_cnth, cc_cnth2, rptFileCrossSame ); 
) // end of program counter_test 

task reset_counter ( ) 
{ 

©0 counter -start = en- 
counter, stop = 1; 
©2 counter .count == 0; 
}//end reset_counter 

task drivers top ( integer num_times ) 
{ 

repeat ( num_ times ) 
{ 

61 counter. stop = 1; 

62 counter . count ==0; 

} 

)//end drive_stop 

task drive_counter ( integer num_times ) 
{ 

integer exp_count, i; 

printf ('Driving counter %0d times — num_times) ; 

repeat ( num_times ) 

{ 

60 counter. count == 3'dO; 
exp_count = 0 ; 

61 counter. start =1; 

for ( i = 0; i < 8; i++ ) 

61 counter . count == exp_count++; 
60 counter. stop =1; 

62 counter. count == 3'dO; 
}//end repeat 

)//end drive_counter 
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This example creates a coverage definition that declares 8 legal states and 7 legal transitions. 
Then the main program instantiates two coverage objects. The counter is driven multiple times 
and the states and transitions are monitored by the coverage objects. The resulting coverage 
report is: 

cc_cnth cc_cnth2 # hits 



s_0 


s_0 


9 


s_0 


t_s_0_7_s_0 


9 


s_l 


s_l 


9 


s_l 


t_s_0_s_l 


8 


s_2 


6_2 


9 


s_2 


t_s_l_s_2 


"9 


s_3 


s_3 


9 


s_3 


t_s_2_s_3 


9 


s_4 


s_4 


9 


s_4 


t_^s_3_s_4 


9 


s_5 


sJS 


9 


s_5 


t_s_4_s_5 


9 


s 6 


s_6 


9 


s_6 


t_s_5_s_6 


9 


s_7 


s_7 


9. 


£_7 


t_s_6_s_7 


9 


t_s_0_7_s_ 


0 s_0 


9 


t_6_0_S_l 




8 


t_s_l_s_2 


6_2 


9 


t_s_2_s_3 


6_3 


9 


t_s_3_s_4 


s_4 


9 


t__S_4_E_5 

t_s_5_£_6 


6_5 

s_6 


9 
9 


t_s_6_s_7 


s_7 


9 
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Maximum Coverage Instance bin combinations: 256 
Detected Coverage Instance bin combinations: 24 
Percentage combinations : 9 - 375 

This coverage report lists all of the states for each coverage object, and the number of times the 
other coverage object observed a state activity or transition activity during the state. 

11.7 Backward Compatibility 

Vera continues to support an earlier version of functional coverage that was not integrated 
into the object-oriented framework. In this implementation, you declare a coverage block for 
each state variable you wish to check. These coverage blocks are then automatically invoked 
each time the state variable changes. 

Coverage blocks need to be declared in the main program, either before the program keyword 
or immediately after 

coverage_block name 
{ 

<vector declaration> 
<state declaration:*-* 
<transition declaration^ 
<coverage options> 

} 

The vector declaration is a list of Vera input or inout signals as specified in an interface state- 
ment. Sampling is done at the edge associated with the first signal. 

The state declarations associate a name with a numeric value, defining all of the legal states. 
The statements are of the form: 

state name number; 
The transition declarations come in two forms. Self-transitions are of the form: 
transition name: name; 

which says we will allow a transition from name to name. More general transitions are speci- 
fied with: 

transition source: destl, dest2, dest3; 
which specifies transitions from source to any of the specified destinations. 

1 1 .7.1 Coverage Options 

The coverage options for the earlier version of functional coverage are: 
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Coverage option Effect 

illegal.state Reports when an illegal state is entered 

UlegaLtransition Reports when an illegal transition occurs 

iUegal.selLtransition Reports illegal self-transitions when enabled 

The default is for all self transitions to be legal. However, if it is not valid to stay in a state for 
more than one cycle, you can use this option. In this mode, you must specify the self-transi- 
tions that are valid. All other self-transitions are reported as illegal. 

11.7.2 Coverage Reporting 

All of the coverage tasks that were outlined earlier (except CROSS) work with coverage 
blocks. A call to coverage(REPORT) produces a report that details the status for all the speci- 
fied legal and illegal transitions: 

**** VERA Coverage Report for fsm_check ****** 
<src> <dst> <num> <last_cycle> 

IDLE PEND 5 5428 

IDLE WRO 22 4543 

IDLE RDO 24 3854 

PEND IDLE 0 



VERA COVERAGE ERROR: PEND -> IDLE transition is not covered 

11.7.3 Conditional Coverage 

Sometimes it is necessary to have finer visibility into the state-machine behavior than just 
which states and transitions were taken. In this case, adding pseudo-states can often provide 
the requisite refinement For example, we can cover state transitions driven by a control signal 
by creating two IDLE states: 

coverage fsnc_check_i { 

vector fsm.cntl, f sm. state; 

state PEND 5'bxOOOl;// first bit does not affect state 

state IDLE_Z S'bOOOOO; 

state IDLE_0 5'bl0000; 

trans IDLE_Z , PEND;// transition while cntl==0 

trans IDLE_0, PEND;// transition while cntl— 1 

> 

We check for transitions from the IDLE to the PEND state, but now for both possible values of 
the fsm.cntl signal. 
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Example 6: Coverage Analysis 

This is an example using functional coverage analysis. The example includes these features: 

• State and transition coverage 

• Coverage options 

• Coverage values 

• Coverage object triggering 

This example includes these files: 

• globaldef.h 

• memCtl.if.vrh 

• Ttwin.m 

• coveragcvr 

• RUN (a run script) 

The RUN script generates a header file for coverage.vr. 

Files included in the distribution but not shown here include: 

• vsg.vrh . 

• stimgen.vrg 



globaldef.h 

#ifndef FILE_GLOBALDEF_H 
♦define FILE_GLOBALDEF_H 

enum MEM_SEG = MEM_SEGO f MEM_SEG1 , MEM_SEG2 ; 

enum COVERAGE_VAL_OPT = GENERIC_COV, STATE_COV, TRANS_COV; 

♦define W_NOOP 1 

♦define W_FLUSH_CACHE 2 * 
♦define W_BURST_READ 8 
♦define W_SINGLE_READ 4 
♦define W_BURST_WRITE 7 
♦define W_SINGLE_WRITE 3 

♦endif 
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memCtl.if.vrh 



tifndef INC_MEMCTL_IF_VRH 

# define INC_MEMCTL_IF_VRH 

#define INPUT_EDGE PSAMPLE 

# define OUTPUT_EDGE PHOLD 

Idefine OUTPUT_SKEW #1 

interface memCtl 
{ 

input [3:0] mc_state INPUT_EDGE ; 

inout [2:0] cmd INPUT_EDGE OUTPUT_EDGE OUTPUT_SKEW ; 
inout cache_hit INPUTJEDGE OUTPOT_EDGE OUTPUT_SKEW ; 
inout cache_dirty INPUT_EDGE OUTPUT_EDGE OUTPUT_SKEW ; 
input elk CLOCK ; 
} // end of interface memCtl 

port mport 
{ 

mcjstate; 
cmd; 

cache_hit; 
cache_dirty; 
}//end mport 

bind mport mbind 
{ 

mc_state memCtl .mc_state; 
cmd memCtl . cmd; 
cache_hit memCtl .cache_hit; 
cache_dirty memCtl.cache_dirty; 
}//end bind 

#endif 



main.vr 



# include 



<vera_de fines . vrh> 
"RTL/memCtl.vh* 



{include 



# include 



•memCtl. if .vrh* 



# include 



• coverage . vrh ■ 

•stimgen.vrh" 

•vsg.vrh' 



# include 



# include 



program coverage_example 



t_CmdLCov 



CmcLCov; 
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t_MemCtl_Cov MemCtl_Cov; 
t_CmdPacket CmdPacket; 
event e vt_new_cmd ; 

// instantiate command packet 

CmdPacket = new; 

CmdPacket. command = NO_OP; // just to initialize before coverage begins 
// instantiate coverage objs 

MemCtl_Cov = newcov (mbind.$mc_state, © (posedge CLOCK), HI, 

100, GENERIC_COV) ; 
Cmd_Cov = newcov ( CmdPacket .command, sync ( ALL, evt_new_cmd ) ); 

print f (•########## GENERATE SEQUENCE FOR GENERIC COVERAGE 

##########\n\n-) ; 
genera te_t est with mbind ( ) ; 

coverage ( CROSS , MemCtl_Cov, Cmd_Cov , • generic . rpt ■ ) ; 
}//end program 

coverage.vr 

# include <vera_def ines .vrh> 
# include ■ RTL/memCt 1 . vh ■ 
♦include ■memCtl. if -vrh - 
# include •stimgen.vrh' 

extern t_CmdPacket CmdPacket; 

// Coverage Obj Type t_MemCtl_Cov 

// cover the command state -machine -values 

// and the transitions among them 

// single- transitions are listed to prevent bacLtrans (not trans) 
// from catching transitions defined in multiple -trans bins - 
// but not covered individually 

// coverage_val is calculated by 3 types of coverage- levels controlled 
// by argument 4 

coverage_def t_#emCtl_Cov (bit (3:0] mc_state, integer cov_opt, 
integer cov_goal, COVERAGE_VAL_OPT cov_val_opt ) 

state 6.IDLE ( IDLE ) , 6_FLUSH_C( FLOSH_C ) , s_LOAD_C ( LOAD.C ) , 
6_START ( START ) , s_B_RD0 ( B_RD0 ) , 6_B_RD1 ( B_RD1 ) , 
s_B_RD2 ( B.RD2 ), 6_B_RD3 ( B_RD3 ) , 6_S_RD ( S_RD ), 
S_S_WR ( S_WR ).., sjBJWRO. ( B^WRO. ) , ^.WRl ( B_WR1 ), 
s_BJWR2 ( BJWR2 ), 6_b1Wr3 ( 1ilWR3 ); 
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state s_B_RD ( B_RD0:B_RD3 ) , s_B_WR ( B_WR0:B_WR3 ) ; 

state s_all_RD ( S_RD, B_RD0 : B_RD3 ) , s_all_WR ( S_WR, B_WR0 : B_WR3 ); 
bad_state < not state ) ; 

trans t_Noop ( IDLE -> IDLE ) if ( mbind. $cmd === NO_OP) , 
t_CacheHit ( -s_IDLE' -> *s_START*. ) 

if ( mbind. $cmd I -- NO_OP && mbind. $cmd !== FLUSH__CACHE 

&& mbind. $cache_hit === 1 ), 
t_CacheMiss ( -s_IDLE- -> LOAD_C -> " s_START ■ ) if ( mbind. $cmd !== 

NO__OP && mbind. $cmd ! == FLUSH_CACHE && mbind. $cache_hit === 0 

&& mbind. $cache_dirty === 0 ), 
t_CacheMissDirty ( IDLE -> 's_FLUSH_C* -> L0AD_C -> START ) 

if ( mbind. $cmd !== NO_OP && mbind. $cmd !== FLUSH_CACHE 

&& mbind. $ each e_h it === 0 mbind. $cache_dirty === 1 ) , 
t_FlushCache ( IDLE -> FLUSH_C -> IDLE ) if ( mbind. $cmd ~= 

FLUSH_CACHE ) , 

t_BurstRead ( START -> B_RD0 -> B_RD1 -> B_RD2 -> B_RD3 ) 

if ( mbind. $cmd ™= BURST_READ ), 
t_SingleRead ( START -> S_RD ) if ( mbind. $cmd === SINGLE_READ ), 
t_SingleWrite ( START -> S_WR ) if ( mbind. $cmd === SINGLE_WRITE ) , 
t_BurstWrite ( START -> B_WR0 -> B_WR1 -> B_WR2 -> B_WR3 ) 

if ( mbind. $cmd == = BURST_WRITE ) ; 

// All Valid Single Trans 

trans ( IDLE -> START ) , ( IDLE -> LOAD_C ) , ( LOAD_C -> START ) , 

( FLUSH_C -> LOAD_C ) , ( IDLE -> FLUSH__C ) , ( FLUSH_C -> IDLE ) , 
( START -> B_RD0 ) , ( B_RD0 -> B_RD1 ) , ( B_RD1 -> B_RD2 ) , 
( B_RD2 -> B_RD3 ) , ( B_RD3 -> IDLE ) , ( S_RD -> IDLE ) , 
( S_WR -> IDLE ) , ( START -> B_WR0 ) , ( B_WR0 -> B_WR1 ) , 
( B_WR1 -> B_WR2 ) , ( B_WR2 -> B_WR3 ) , ( B_WR3 -> IDLE ) ; 

bad_txans ( not trans ) ; . » 

coverage_option = cov_opt ; 
case ( cov_val_opt ). 
( 

GENERIC_COV : 

coverage_val = query ( NUK_BIN, TRANS | STATE GT, 0 ) 

/ query ( NUM_BIN, TRANS | STATE , •.*"); 
STATE_COV : coverage_val = query ( NUM_BIN, STATE, • . *• , GT, 2 ) 

/ query ( NUM_BIN, STATE, ".*•); 
TRANS_COV : 

cqverage_val = query ( NW_BIN, TRANS, •.*",GT, 2 ) 
/ query ( NUM_BIN, TRANS, *.*•); 
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}//end case 

coverage_goal = cov_goal / 100; // in fraction 
}//end t_MemCtl_Cov 

// Coverage Obj Type t_Cmd_Cov 

// covers the commands and some selected transitions between them 

coverage_def t_Cmd_Cov ( bit [2:0] cmd__value ) 
{ 

state s_NO_OP ( NO_OP ) , s_BURST_READ ( BURST_READ ) , 

S_SINGLE_READ ( SINGLE_READ ) , s_BURST_WRITE ( BURST_WRITE ) , 
S_SINGLE_WRITE ( SINGLE_WRITE ) , s_FLUSH_CACHE ( FLUSH_CACHE ) ; 

bad_state ( not state ) ; 

trans back_to_back_burst_rd ( BURST_READ -> BURST_R£AD ) , 
back_to_back_burst_wr ( BURST.WRITE -> BURST_WRITE ), 
t_BUKST_READ_BURST_WRITE ( BURST_READ -> BURST_WRITE ) , 
t_BURST_WRITE_BURST_READ ( BURST_WRITE -> BURST_READ ) ;' 
trans t_ALL_WRITE _ALL_READ ( [ BURST.WRITE , *s_SINGLE_WRITE- ] 
-> [ • s_BURST_READ " , S INGLE_READ ] ) ; 

coverage_option = HI; //needed to do cross coverage 
}//end t_Cmd_Cov 

RUN 

#!/bin/csh -f 

rm -f *.vro core *.vshell >& /dev/null 
vera -cmp -g -h coverage. vr 
if ($status) exit 1 
vera -cmp -g main. vr 
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12. Multiple Module Support 

This chapter introduces Vera's multiple module support It describes the different components 
of multiple module support and details how they are used. This chapter includes these sec- 
tions: 

• Introduction 

• Overview 

• Project Files 

• Configuration Files 

• Generating a Project-based Configuration 

Note - Multiple modules are not yet supported for VHDL. ■ 



12.1 Introduction 

Thus far, we have described how to create Vera testbenches as monolithic, single programs 
that are connected to the simulation through one of two methods: the test-top method and the 
HDL node method. In addition to these methods, Vera supports a project-based configuration 
methodology that allows you to create testbenches with multiple modules. 

Using the test-top method, the Vera shell is instantiated as a component in a test-top file that 
was either generated by the Vera template generator or created manually. This method has the 
advantage of keeping the Vera test-bench source code independent of the actual connection to 
the simulation, which allows you to use the test-bench in multiple simulation environments 
without having to recompile the code. However; the test-top method forces you to have a test- 
top level on which all connections between the test-bendi and simulation nctust be made. This 
, ' limitation is significant when making connections deep in the hierarchy o^ the simulation 
structure. * , .-- 

The HDL node method uses constructs in the interface files to connect directly to the simula- 
tion environment without the need for a test-top file This method allows you to easily make 
connections between the test-bench and the simulation environment, even at points deep in 
the hierarchy of the simulation structure. However, using the HDL node method forces you to 
use test-bench source code that is dependent on the connection to the simulation. Therefore, 
you must recompile the source code each time the connection is changed. 
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Vera's implementation of project-based configuration grants you the advantages of both earli- 
er alternatives without the limitations associated with each. Project-based configuration allows 
. you to create test-benches that are independent of the actual connections to the simulation en- 
vironment and connect those benches to any point in the simulation hierarchy without the 
need for a test-top configuration. 

Project-based configuration has the added advantage that Vera test-benches can be treated as 
modules that can be instantiated multiple times and run concurrently in a single simulation. 

The power offered through the project-based methodology is substantial even for users who 
prefer a monolithic approach, and it can be used without the multiple program capabilities. 

12.2 Overview 

This section gives a brief overview of the components of the project-based configuration ap- 
proach. 

Vera's multiple module support is based on its implementation of project-based methodology. 
There are three major components to this approach: 

1. An overall project (.proj) file specifying testbenches used in the simulation 

2. A configuration (.vcon) file for each testbench module 

3. The Vera object (.vro) files for each testbench module type 

Project Files 

The project file specifies which modules are used in the simulation. For each testbench module 
being used, the project file must have a corresponding section that specifies the module name, 
the configuration file, and the Vera object files associated with that particular module. 

Configuration Files 

Each testbench module must have a corresponding configuration file! The configuration file 
specifies how the module is connected to the simulation. It connects Verilog signals to Vera in- 
terfaces. Configuration files also specify any docks that are needed, declare all Vera-Verilog 
task calls, and define dock generators with a specific period and timing. . 

Note that the connections between the Verilog signals and the Vera interfaces can be changed 
in the configuration files without recompiling the testbench source code. 

Vera Object Files 

The Vera object files are binary files created when the source (.vr) files for the testbench mod- 
ules are compiled. A separate object file is required for each testbench. 
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12.3 Project Files 

The project file contains information for each testbench module being used in the simulation. 
Each module is listed, followed immediately by a list of the configuration file and object files 
associated with the module. The syntax for the project file is: 

*n» 4 t* modulel^name 
modu 1 el_name . vcon 
modulel_objectl . vro 

modulel_objectN. vro 



main modal eN_name 
moduleN__name . vcon 
moduleN^obj ectl . vro 

modulell.objectN.yrro 

Each module definition begins with the main keyword and is followed by a modulejxame. The 
module jname is simply a unique instance name for the module. The definition line is followed 
by lines specifying the configuration file and all Vera object files associated with that module. 

You can include a modulejname.wri file in place of the Vera object files. 

The project file can contain Vera pie-processor directives and macros such as #include and 
#define. The normal Vera style comments (// and /* ~ V) are also supported in the project 
file. 



12.4 Configuration Files 

The configuration file contains the information specifying how the testbench module is con- 
nected to the simulation. Most importantly, it indicates how signals are connected between the 
testbench and DUT, and it defines dock generators. 

The syntax for a configuration file is: 

time scale timescale^statement 
clock clock^sta Cement 
connect connect_statement 
veritaik Veritas ^statement 

Each of these statements is discussed in detail in subsequent sections. 

12.4-1 Timescale Statement 

The timescale statement sets the time between dock ticks. The syntax is: 
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time scale timescale_description 
titnescalejAescription - The timescalejdescription is in the form of a nprmal Verilog timescale. 

The timescale statement is optional. If you include a timescale statement in the configuration 
file, an equivalent Verilog 'timescale statement is generated in the Vera shell file. 

1 2.4.2 Clock Statement 

The clock statement creates a clock generator in the Vera shell file, which drives the specified 
Vera clock. The syntax is: 

clock clock^name period period\_number offset initial_value 

clock_name - The clockjname is the name of the Vera clock. It is specified as either 
SystemClock or interface jnaine .clock jname. 

periodjnumber - The period jnumber specifies the cycle length for the clock in nanoseconds. 

offset - The offset sets the delay before the clock changes for the first time. The default is 0. 

initialjoalue - The initial joalue is the value the clock starts at (either 0 or 1). The default is 0. 

The clock statement is optional. If a Vera clock does not have a clock statement and is not con- 
nected to any Verilog node through a connect statement, it will be listed in the I/O list as an 
input to the Vera shell module (except for SystemClock, which will never be listed as output in 
the I/O list). . 

Finally, if a Vera clock has a connect statement, with or without a clock statement, it will not be 
listed in the I/O list of the Vera shell module. 

12.4.3 Clock.alias Statement 

The clock_alias statement aliases a Vera clock to another Vera dock. The syntax is: . 
clock_&lias clockLnaael = clocJC.name2 

A clock cannot have a dock statement and be on the left-hand side of the dock_alias state- 
ment This is disallowed because it assigns two docks to the same dockname. Such assign- 
ments generate compilation errors. 

12.4.4 Connect Statement 

The connect statement connects a Vera signal or dock to a specified Verilog node. The syntax 

is: 

connect direction vera_name verilog^joame . skew skew_value 
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direction - The direction can be one of the following:' in, input, out, output, or inout. The in or 
input direction specifies clocks and signals into Vera from the DUE The out or output 
direction specifies clocks and signals out from Vera into the DUT. The inout direction 
specifies bidirectional signals. The direction is checked against the direction specified in the 
interface. Mismatches result in compilation errors. If the direction is not specified, the 
direction is taken from the Vera interface. The direction for Vera clocks is ignored. 

verajname - The verajname is the name of the Vera signal you are connecting to the DUT. The 
format for the verajname is interface_name.signaljname, where the interface and signal are 
specified in the interface specification. 

verilogjname - The verilogjname is the name of the Verilog signal to which the Vera signal is 
being connected. It should include the Verilog hierarchal path. If the verilogjname is not 
specified, the Vera signal is not connected directly to a Verilog node. Instead, that signal is 
assumed to be connected through the I/O port list of the Vera shell module. This is useful 
if the Vera-shell is explicitly instantiated and connected to the simulation through the 
module ports. In this case, the port name used would be interfacejnamesignaljname. 

skew - The skew can be either iskew (input skew) or oskew (output skew). The default is no 
skew. 

skewjoalue -The skewjoalue is the length of the skew type specified. If you specify input skew, 
the skewjoalue should be 0 or negative. If you specify output skew, the $kew_value should 
be 0 or positive. The default skewjoalue is 0. 

The connect statement is necessary to connect the Vera testbench signals to the DUT. 

12.4.5 Veritask Statement 

The veritask statement maps a Vera task name to a Verilog task path in a Vera-Verilog task call. 
The syntax is: • 

veritask ver^tasJt_name = yerllog_taski_name 

verajtoskjname - The verajaskjname is the name of the Vera task being mapped to Verilog. 

verilog Jtaskname - The [v^ogjaskjtame is toe Verilog name of the Vera task. It should 
include the Verilog hierarchal path. - . . 

This statement is optional. If it is missing for a Vera-Verilog task call a warning is printed and 
the default (the original pa* from the veritask statement in the Vera source code) is used. 

12.5 Generating a Project-based Configuration 

To generate a project-based configuration with multiple modules: 

1. Compile the source code for the individual testbench modules. 

This generates the Vera object files and Vshell files required to run the sim^ilatiojt with the 
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testbenches. 

2. Create a configuration file for each testbench module. 

If the testbench source files are available, you can generate a template configuration file by 
typing: 

vera -vcon program. vr 

program - The program.vr contains the program block for the module. 

You must then customize the template configuration file as necessary by specifying sig- 
nal connections, clock periods, and any Verilog tasks that need to be defined in the con- 
figuration file. It is important that the signals are connected to the correct Verilog nodes. 

3. Create an overall project file that contains information on all modules necessary for the simu- 
lation. 

4. Create Vera shell files for each testbench module listed in the project file: 

vera -proj file.proj 

This generates a Vera shell file called modulewzmejshe]l.v for each module. This Vera 
shell file is used during the Verilog compilation. The Vera shell file is generated from the 
Vshell (.vshell) file created when the testbench source code was compiled. 

5. Run the simulation with the +vera_pload switch: 

verilog +vera_pload=proj_name.proj jnodl_shell. v ... jnodW_shell . v 

The above flow eliminates the need for a test-top file that instantiates the Vera shell module. 
However, you can still use the test-top file approach with a project-based approach by deliber- 
ately not specifying connections for Vera interface signals in the .vcon file. Unspecified inter- 
face signals result in a printed warning message during Vera shell creation. The signals are 
automatically listed as I/O signals in the Vera shell module. The Vera shell module must then 
be connected to the rest of the simulation by instantiation. 

Note - It is possible to mix the two approaches in a single project file 
where only some test-bench modules require instantiation. 
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Example7: Multiple Modules 

This is an example of multiple module usage. This example includes these files: 

• SyncMemMon.vr 

• SyncMemMotuvcon 

• SyncMemTestvr 

• SyncMemTest.vcon 

• multimod.proj 

• RUN (a run script) 

Files included in the example distribution but not present here include: 

• publicjasks.vr 

SyncMem.if.vrh 

interface SyncMem_if 
{ 

inout CE OUTPUT_EDGE OUTPUT_SKEW INPUT_EDGE; 
inout OE OUTPUT_EDGE OUTPUT_SKEW INPUT_EDGE; 
inout [7:0] AD OUT PUT_EDGE OUTPOT_SKEW INPUT_EDGE; 
inout [31:0] D INPUT_ EDGE PRZ OUTPUT_SKEW; 
input elk CLOCK; 
} // end of interface SyncMem 

globals.vrh 

♦define ADDR^SIZE 8 
♦define DATA^SIZE .32 

SyncMemMon.vr 

♦define OUTPUT_EDGE PRZ 
♦define OUTFUT_SKEW #1 
♦define INPUT_EDGE PSAMPLE 

♦ inc lude <ver a_de f ines - vrh> 

♦ include "public_tasks .vrh - 

♦ include ■ SyncMem. if . vrh" 
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// This program serves as a monitor which runs indefinitely 

// and looks for bad signal values (X and 2) on the OE and CE pins 

// of the verilog SyncMem model. 

// At the same time, it will report any write/read activities to 

// the model by monitoring the CE and OE signal combinations 

program SyncMem_monitor 
{ // start of top block 

// Start of SyncMem. test 

©(negedge SyncMem_if .CE) ;// wait till initial impedence is overriden 

// by test or other connections 

while (1) 
{ 

© (po sedge SyncMem_if . elk) ; 

SyncMenuif -OE = void; // void drive to synchronize 

fork 

{ 

if ( SyncMenuif -CE === l'bl && SyncMenuif .OE === 1'bO ) 
rptWriteMem ( "SyncMenuif - AD" , SyncMenuif . AD , "SyncMenuif .D* , 

SyncMem_i f . D ) ; 
if ( SyncMenuif -OE === l'bl ) 
{ 

©(posedge SyncMem_if.dk); 

rptReadMem ( "SyncMenuif .AD* , SyncMem_if .AD, "SyncMem_if .D* # 
SyncMem. if.D ); 

} 

) 
{ 

if ( SyncMenuif .OE === l'bx ) rptErrorSig ( "SyncMenuif .OE* , 
1#bx >'* 

if ( SyncMenuif .OE === l # bz ) rptErrorSig ( "SyncMenuif .OE" , 
l*bz ); 

) 
{ 

if ( SyncMenuif .CE === l'bx ) rptErrorSig ( " SyncMenuif . CE • , 
l'bx ); 

if ( SyncMenuif .CE === l'bz ) rptErrorSig < "SyncMenuif .CE* , 
1'bz ); 

) 

join all 

)//end while v ; . . 

) // end of program SyncMenutest - : , . V ; 
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SyncMemMon.vcon 

clock SyncMem_if .elk period 100 
connect inout SyncMem_if . CE=SyncMem. CE 
connect inout SyncMem_if . OE= SyncMem . OE 
connect inout SyncMem_i f . AD= SyncMem . AD 
connect inout SyncMem_i f • D=SyncMem . D 
connect output SyncMem_if . clk= SyncMem. elk 
// timescale lOOns/lOns 
clock SystemClock period 100 



SyncMemTest.vr 

#define OOTPOT_EDGE PHOLD 
idefine OUTPUT_SKEW #1 
tdefine INPUT_EDGE P SAMPLE 

# include <vera_def ines .vrh> 
f include 'globals .vrh' 
finclude -public.tasks . vrh' 
# include ■SyncMem. if .vrh - 

// This test will write to the verilog SyncMem model 
// data = (addr + 5) from addr 0 -> 255 
// Then it will read back the data and verify them in 
// reverse order of addresses. 

program SyncMem_test 
{ • 

integer i; 

// Start of SyncMem_test 

reset_mem(); ....'■* 

printf C setting data \n' ) ; 

for ( i = 0; i < 256; i++ ) 
set_data ( i , i ^ 5 ) ; 

printf C getting data \n m ); 

for ( i = 255; i >= 0; i— ) 
if <get_data(i> !== (i+5)) 

error ("inconsistent data in memory location %0d getting 
expecting %0h\n' , i, get_data(i), i+5 ) ; 

printf (' all done \n-); 

exit (1); // to terminate simulation altogether 
} / / end of program SyncMenv_test 
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task reset_mem ( ) 
{ 

61 SyncMem_if -OE = 0; 
SyncMem_if .CE = 0; 
SyncMen\_if .AD = 8'bZ; 
SyncMem_i f „ D = 32 'bZ; 
61 SyncMenuif .D = 32 'bZ; 
}//end reset jnem 

task set_data ( bit [ADDR_SIZE-1:0] wrAddr, bit [DATA^SIZE-1 : 0) wrData ) 
{ 

61 SyncMenuif .OE = 0; 
61 SyncMenL.if.CE = 1; 
SyncMem_i f . AD = wrAddr; 
SyncMem_if.D = wrData; 
61 SyncMem_if .OE = 0; 
SyncMem_if.CE = 0; 

61 SyncMem_if-D == void; //void expect 
}//end set_data 

function bit [DATA_SIZE-1: 0] get_data ( bit [ADDI^SIZE-l: 0] rdAddr ) 
{ 

61 SyncMenuif.OE = 1; 
SyncMem_i f . AD = rdAddr; 
6(posedge CLOCK); " 
get_data = SyncMem_i f . D ; 
61 SyncMem_if .OE = 0; //void drive 
}//end get_data 



connec t inou t S yncMem_i f . AD= SyncMem . AD 
connect inout SyncMem_i f . D= SyncMem . D 
connect output SyncMem_if .clk=SyncMem.clk 
// timescale lOOns/lOns 
clock SystemClock period 100 



SyncMemTestvcon 



clock SyncMem_if .elk period 100 

connect inout . SyncMen\_if .CE= SyncMem. CE 

connect inout SyncMenui f - OE = SyncMem . OE 
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13. Vera-CORE 

This chapter introduces Vera-Core and describes how it used. It includes these sections: 

• Introduction 

• Vera-CORE Usage Model For IP Vendors 

• Vera-CORE Usage Model for IP Users 

13.1 Introduction 

O Developers of ASICs often look outside of their own firm for help in creating complex circuits. 

C= They purchase synthesizable modules (IP cores) from IP vendors, and integrate .the cores into 

Nj their pjL descriptions. Using IP cores provides two very important advantages for the devel- 

5j opers: it shortens the development time, and it allows them to purchase debugged, robust 

=1 modules. 

W However, while offering distinct advantages, their is an element of risk in using IP cores. Be- 

W cause developers are generally not as knowledgeable of others' work, latent bugs in the cores 

;L r can lead to enormous losses of time. Additionally, bugs can be introduced to the ASIC design 

iff by improper connection or use of the cores. 

H Because these bugs can spell disastrous results for both the vendors and developers, both 

[U groups must strive to eliminate such problems. In doing so, the traditional approach has been 

p to include monitors with the IP cores that catch problems and notify developers. The monitors 

° pk are used to check for protocol violations by the system, to check for protocol violations by the 

core itself, to check for internal error states within the core, and to accumulate ^est coverage 

information at the core boundary and within the core. 

Traditionally, these monitors have been embedded in ^'^^y^VdS^vOA. However, 
the inherent flaws with Verilog in creating and mamtainmg complex m<>nitors : have made such 
solutions very limited and incomplete. -:c : .. \'- . . 

While Verilog is generally inadequate for such tasks, Vera is a language explicitly designed for 
expressing these monitoring functions. Vera's multiple module support, flexible connection 
scheme, and project-based configuration capabilities make Vera a superior tool for developing 
such checking mechanisms. Moreover, Vera has the unique capability to support Vera modules 
written by IP vendors without the need for regular Vera runtime licenses, this means mat de- 
velopers can run simulations using the IP cores (written in Vera) without purchasing Vera li- 
censes by simply connecting the testbench signals to the hierarchal DUT signals where the 
Vera-CORE is to be stitched. "- " A 
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A general flow diagram of Vera-CORE is shown in Figure 13-1. 




f Generator ) , 



IP Provider 



IP User 




Figure 13-1 General Vera-CORE flow diagram 

13.2 Vera-CORE Usage Model For IP Vendors 

This section details how IP vendors use Vera to integrate monitors into their IP cores so that 
developers can use the cores in their simulation environment 

The steps to create the Vera-CORE file set are: 

1. Include monitors and coverage objects within the Vera source (.vr) files. 

2. Compile to 

used without a Vera nmtime license. ' : r : ^ r 

3. Create the configuration file: 
vera -vcon filename.vr 

filename - The filename is the name of the IP core source file. 

4. Create the project file for the IP core including the configuration and object files to be used. 

5. Create tine Vera shell files: 
vera -proj filename. pro j 

filename - The filename is the name of the IP core project file. 
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6. Distribute the resultant Vera shell files (shell, v), object files (.vro), configuration files (.vcon), 
and project file (.proj). 

1 3.3 Vera-CORE Usage Model for IP Users 

This section details how IP users use Vera-CORE files without a Vera runtime license. 
To use Vera-CORE files: 

1, Download the Vera-CORE runtime library from the Synopsys ftp site. 

Z Modify the existing configuration files to make direct signal connections between the IP core 
and the HDL design. Each testbench signal must be connected to the hierarchal signal path 
where Vera-CORE is to be stitched. 

3. Create a Vera list file (.vrl) that includes the project (.proj) and module (shelLv) files. 

4. Run the Verilog simulation using this switch: 
+vera_jnload=f i lename . vrl 
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Example 8: Vera-CORE 




This is an example of Vera-CORE usage. This example includes these files: 

• counter.if.vrh 

• counter jchecker.vrh 

• counter jchecker.vr 

• counter jchecker. vcon 

• counter jchecker.vrl 

• counter ^checker. pro j 

• counter _coverage.vrh 

• counter jcoverage.m 

To generate this Vera-CORE usage model you should: 
1. Generate the test-top file, interface file, and Vera source file: 
vera -temp -t counter -c elk counter. v 

This creates the files counter.testjop.v, counter.if.vrh, and counter. vr Amp. 
Z Edit the counter.if.vrh interface file to make the signal connections. 

3. Generate the configuration (.vcon) file: 
vera -vcon counter.checker . vr 

4. Edit the counter jchecker. vcon file to make the correct signal connections. 

5. Instantiate counter_checker_shell inside the DUT. 

6. Use the RUN script 



#ifndef INC_COUNTER_IF_VRH 
♦define INC_COUNTER w IF_VRH 

// Note: counter.if.vrh is edited so that all signals are inputs 

interface counter_checker 

{ 

input rst_n PSAMPLE ; 
input elk CLOCK; 



counter.if.vrh 
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input Qout PSAMPLE; 

input [3:0] COUNT PSAMPLE verilog_node "counter .count_r eg [3 : 0] • ; 
} // end of interface counter 

#endif 



# include ■ counter .if .vrh' 

# include • counter_coverage . vrh " 

program Counter_Checker 
{ 

reg [3:0] count; 

counter_sn*_cov cntO = 

newcov (counter_checker. COUNT, e(counter_checker. elk) ) ; 
while(l) 
{ 

if (count er_checker.rst_n ==1) 



mycount=%d\n • , counter_checker . Qout # count) ; 
if (count == 4'd9) 
{ 

60 counter_checker . Qout ==1; 
G(posedge counter_checker .elk) ; 
count = 0; 




counter checker.vr 



#define OUTPUT_EDGE PHOLD 
#def ine OUTPUT_SKEW #1 
#define INPUT_EDGE PSAMPLE 
# inc lude < vera_de fines . vrh> 



print f ( 'count er_checker. Qout ==%b. 



else 



{ 



60 count er_checker . Qout == 0; 
© (posedge counter_checker . elk) ; 
count = count +1; 
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} 

else 
{ 

@ (po sedge coun ter_checker . c Ik ) ; 
count = 0; 

counter_checker.Qout == 0; 

} 

coverage ( REPORT , cnt 0 , • counter_FSM . rpt • ) ; 
} //end of while (1) 
} // end of program counter_test 



counter_checker.vcon 

//clock counter. elk period 100 

connect input count er_checker„rst_n= count er_ tb. Ul „rst_n 
connect input count er_checker . c lk= count er_tb .Ul . elk 
connect input count er_checker . Qout=counter_tb . Ul . Qout 
// timescale lOOns/lOns 
clock SystemClock period 100 

counter_checker.vr! 

counter_checker . vro 
counte recover age. vro 

counter_.checker.proj f 

main counter_checker 
counter_checker . vcon 
counter_checker . vxl 

counter_.coverage.vrh 

#ifndef INC_TOP_COUOTER_COVERAGE_VRH 
♦define INC_TMP_COUNTER w COVERAGE_VRH 

enum counter.states = SO, SI, S2, S3, S4, S5, S6, S7, S8; S9; 
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extern coverage_def counter_sm_cov 
( 

bit [3:0] count_state 

); 

iendif 

counter_coverage.vr 

* include <vera_def ines . vrh> 
# include •counter. if .vrh" 



enum counter_states 


SO 


= 4'h0, 


SI 


= 4'hl, 


S2 


= 4'h2, 


S3 


= 4'h3, 


S4 


= 4'h4, 


S5 


= 4'h5, 


S6 


= 4'h6, 


S7 


= 4'h7, 


S8 


= 4'h8, 


SS 


= 4'h9; 



coverage_def counter_sm_cov (bit [3:0) count_state) 
{ 

state sO (SO) , si (SI) . s2 <S2) ,s3 (S3) ,s4 (S4) , s5 (S5) , s6 <S6) , s7 (S7) / 

s8(S8),s9(S9); 
bad„state (not state); 

trans reset (S0->S0) ; 

trans s0_sl (S0->S1) ; 

trans sl_s2 (S1->S2) ; 

trans s2_s3 <S2->S3) ; 

trans s3_s4 (S3->S4) ; 

trans s4_s5 (S4->S5) ; 

trans s5_s6 (S5->S6) ; 

trans s6_s7 (S6->S7) ; 

trans s7_s8 (S7->S8) ; 

trans s8_s9 (S8->S9) ; 

trans s9_s0 (S9->S0) ; 
bad_ trans (not trans) ; 

coverage_option = HI; 
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RUN 

# ! /usr/bin/csh -f 

vera -cmp -ip -h -I. counter.coverage . vr 
vera -cmp -ip -I- count er_checker . vr 
Is *vro > counter_checker,vrl 

echo •main counter_checker' > counter_checker -proj 
echo "counter_checker. vcon* » count er_checker.proj 
echo counter_checker . vr 1 » counter_checker ,proj 

vera -proj counter_checker.proj 
verilog +vera_pload=counter_checker .proj \ 
count er_checker_she 11 . v . /counter . v 



01 
bJ 
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14. Vera-to-HDLTask Calls 

Vera is an HDL co-simulation. Because of the close interaction between the two simulators in 
the verification process, it is often useful to call tasks across platforms. For this reason. Vera 
enables you to call HDL tasks from within Vera and also provides a means to call Vera tasks 
within HDLs. This chapter discusses how to make these calls and includes these sections: 

• Calling HDL Tasks from Vera 

• Calling Vera Tasks from Verilog 

14.1 Calling HDL Tasks from Vera 

Vera allows you to call HDL tasks from Vera and transfer data back and forth between Vera 
and the HDL. To declare an HDL task in Vera, use the following syntax within your main pro- 
gram module: 

verilog_task taskjname ( arguments) ■ inst_path m ; 
vhdl.task taskjname {arguments) m inst_path m t 

taskjname - The taskjname is the name of the HDL task you want to call. 

arguments - Task call arguments are passed from Vera to the HDL when the task is called. 
Arguments can be of the following types: integer and bit field. Note that you can pass 
strings as bits using this construct bit{(8*stringjength)-l$] str, where string Jength is the 
number of characters in string str. j; 

inst^ath - The inst_path is the instantiation path of the task in the HDL. It identifies the HDL 
task within the HDL hierarchy starting at the top level HDL module.^ : ? . 

This is an example of an HDL task call from within Vera: ^* o r f.-v* 

verilog_task chip_init (bit [7:0] init_reg) ■ top . chip /chip_Init ■ ; 

This example calls the Verilog task chip_init and passes the bit field variable initjreg. The 
task can be found within the top . chip hierarchy in the Verilog declaration. • ' : 

Because Vera identifies this declaration as a task definition, it must occur in the top code 
block. However; if you want to call the HDL task from other files, you can define it as an ex- 
ternal task using the extern construct 

extern verilog_task (arguments); 
extern vhdl_task (arguments) ; 

For example, to declare the chip_init task so it can be called from other files/use: 
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extern verilog_task chip_init (bit (7:0] init_reg) ; 

14.1.1 HDL Tasks in Vera: Outputs/lnouts 

For HDL outputs and inouts, Vera reflects the output value if the Vera formal argument is pre- 
fixed by the var keyword. 

Note - It is important to define the var parameter in the HDL as inout 

This is an example of the var construct with HDL task calls: 

verilog_task get_status (var bit [7:0] status_word) • top. cpu. status ■ ; 

verilog_task chip_init (bit (7:0] init_reg) ; 

{ 

bit [7:0] word; 
integer i; 

chip_init (8 *b0000_0000) ; // OK 
get_status (word) ; //OK 

get_status(i) ; // Error: formal is bit[7:0]; actual is integer 

get_status(8'b0000_0000) ; //Error: formal is var; actual is constant 

} ' ;* 

The task call of chip_init is successful because the Verilog task has been defined to accept 
any bit[7:0] as a parameter. The get_status (word) task call is successful because "word" 
matches the formal variable type specified in the declaration. The get_status (i) task call 
does not succeed because the variable type of the argument (integer) does not match the for- 
mal declaration (bit [7:0]). The get_status (8 'b0000_0000) task call does not succeed because 
the argument passed is a constant and the formal declaration is a variable. 

14.1.2 Type Checking HDL Tasks in Vera 

Vera can check the argument types of HDL task declarations within Vera and any task calls 
made within Vera. However, Vera cannot access the task definition made within the HDL. So 
Vera cannot check the argument types in the Vera program against the argument types in the 
HDL definition. Therefore, you must check that the declarations in Vera are consistent with 
the HDL task definition. 

If the types are not consistent, the results of the task calls are unpredictable. Although the 
right type of implicit conversions may occur, this is not guaranteed. Instead, it is recommend- 
ed that you use types which are consistent in Vera and HDL, and do any type conversion sep- 
arately. 
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Note - This is equivalent to what happens when calling external 
functions in C, where the burden of consistency between the extern 
declarations and the libraries is not on the compiler but on the 
programmer (or on lint). 



14.2 Calling Vera Tasks from Verilog 

Vera provides mechanisms to call Vera tasks from the HDL. Currently this is only available 
with Verilog designs. 

14.2.1 Declaring Vera Tasks for Export 

If you want to call Vera tasks from an HDL, the tasks must be declared with the export con- 
struct in the top level Vera file (the program file):. 

export task task^name {arguments) { 
taskjcontents; 

} 

arguments - The arguments are passed from the HDL to Vera when the task is called. They can 
be of type integer or bit field. Strings can be passed as bits using this construct 
bit[(8*stringjength)~l:0] str, where string Jength is the number of characters in string sir. 
The arguments can be var and non-var variables as welL Default arguments can be 
specified. However, while they will apply to calls made from Vera code, they will not 
apply to calls made from the HDL. 

taskjcontents - The taskjcontents can be any Vera code valid in normal task definitions. 

Note - You can only export global tasks. You cannot export class 
methods or functions because of the restriction of function usage 
within an HDL. 



As an example, examine: 

export task foo (integer num) { 

printf( m Task foo() called with num %0d!!\n*, num ); 

} 

This example declares a task foo and passes the argument num of type integer. 

14.2.2 Calling Exported Vera Tasks 

When you declare an export task, a task with the same name is generated in the vera_shell 
module. It is called from the HDL as vshell . task^name. For example: 
vshell. foo(5) ; 
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However, if the vera_shell exists as a co-top-level module (test-top connections between Vera 
and the HDL signals are done using "HDL_node" constructs in the interface), then the task 
must be called from the HDL as vera__shell . task^name. 

Exported tasks behave as normal Vera tasks and can be called within the Vera code. 

Vera imposes no restrictions on the contents of exported tasks. Exported tasks can have delays, 
forks /joins, and calls to other tasks or functions including calls back to HDL tasks. 



Warning - Though Vera tasks are re-entrant, Vera task calls from an 
HDL are NOT re-entrant because of the Verilog task wrapper inside of 
the vera_shell. 



1 4.2.3 Exporting External Tasks 

Exported tasks must be declared in the program file. However, exported tasks can be external 
Vera task declarations. So the definition of the body of the task can be in a separate subroutine 
file, which is compiled and included separately. If this is the case, only the export extern dec- 
laration has to be in the program file, and only the following line needs to be in the program 
file: 

export extern task task_name {arguments) ; 

The Vera task declaration and task definition can be in the same file. If they are both within a 
program file, you can export the task if either (or both) has the export prefix. 

In a subroutine file, task definitions cannot be of type export The compiler simply ignores the 
prefix in this case. Therefore, a task that is declared as an export extern in a program but 
whose body is defined in a separate subroutine file should not have an export prefix in the 
subroutine file. Whether or not a task is exported depends only on how it is declared (or de- 
fined) in the program file. 
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1 5. Calling C/C++ Functions 

This chapter discusses Vera's handling of C and C++ function calls. This chapter includes these sec- 
tions: 

• Declaration and Invocation 

• UDF Arguments 

• Linking UDFs to Vera 

• PLI Support Procedures 

• Handling Special Events 

15.1 Declaration and Invocation 

All Vera UDFs (user-defined functions) must be declared before they are used, as either tasks or func- 
tions. The syntax to declare a UDF is: 

function datatype $udf_name {arguments); 
task $udf_name (arguments) ; 

dcUaJype - The datajtype specifies the data type returned by the function call. Functions can be of type 
integer, bit, and string. The default data type is integer. 

udfjname - The udf_name is the name of the UDF being declared. 

arguments - The arguments can be arguments of type integer, bit and string, and they can include var 
declarations. 

15.2 UDF Arguments 

UDF arguments must be handled from the Vera side and the C/C++ side. 

15-2.1 Vera UDF Arguments 

The size and type of the UDF arguments in the function or task call must match exactly those in the 
declaration. If they do not, a compilation error occurs. 

For example, this task declaration and call result in a compilation enron 

task $ray_task (integer i); 
$my_task(string_a) ; 
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Vera also supports bidirectional arguments with UDFs using the var construct. Arguments passed using 
the var construct can both pass and receive data when the function or task is called. For example: 

task . $my_task (integer i, var bit [7:0] mydata) ; 

When using bidirectional arguments, you must be careful to type check the call with the declaration. 
For instance, given the above task declaration, this call results in a compilation erron 

$my_task(100,200) ; 

This call results in an error because a constant is passed (200) where a variable is expected (mydata). 

You can specify an unknown number of arguments by using an asterisk (*) in place of actual arguments 
in the function or task call. For example: 

task $my_printf <*) ; 

If you use this construct, the arguments must be of type integer or bit 

15.2.2 C/C++ UDF Arguments 

Integers and strings are passed as is. They do not need a Vera data structure to be passed to Vera, 

The bit vector data structure that Vera uses is: 

typedef struct t_vecval 
{ 

int avalbits; 
int bvalbits; 
} s_vecval, *p_vecval 

The values that this data structure yields depend on the aval and bval integer values. Table 15-1 shows 
the values. 

Table 75-7 Bit vector data structure values 



aval bval Value 

0 0 0 

1 0 1 

0 1 Z 

1 1 "X 



The Vera Data data structure is used to transfer values between Vera and the UDF. The Vera Data data 
structure is: 

typedef struct VERA_DATA 
{ 

int type; •"■ ■ ■ 

union 
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{ 

int int^value; 
char string; 
struct 
{ 

int expr_ngroups; 
int expr_vec_size; 
s_vecval expr_ val ue_p ; 
} bit_val; 
} data; 
} vera_data ; 

type - The type must be VERA JNT.X, VERAJNT, VERA.BIT, or VERA.STRING, depending on 
the value type being passed. The integer equivalents of these types are 1, 2, 3 V and 4 respectively. 

intjrolue - The int_yalue is the integer value of any data being passed. 

string - The string is the string value of any data being passed. It can be NULL if the string on the Vera 
side is NULL. 

expr_ngroups - The exprjngroups is the number of groups in the expression value. 
expr_yec_size - The expr_yecjsize is the number of bits in the expression value. 
exprjvalue j> - The exprjvalue _p is a pointer to the expression value. 

More information concerning this data structure can be found in the Verilog PU Reference Manual. 

15.3 Linking UDFs to Vera 

To link UDFs to Vera, you must modify a UDF table in the verajuser.c file and create object files. 

15.3.1 Vera UDF Table 

To link UDFs to Vera, you must put an entry into the Vera UDF Table for each user routine. The table 
$VERA_HOMEAibfterajuser. c. The syntax for a table entry is: 

v*ra_ua«r_c*ll_entrY Verm_TjDr_Table [ ] = { 

type, *proc^name* , proc, misc_proc, data, "comment* 

) 

type - The type should be either VERA_USER_TASK or VERA.USERJTONC . 

procjnome - The procjuune is the name of the UDF being linked, as it is known to the user. 

proc - The proc is the actual UDF name, as it is called within Vera. It is called with the argument data. 

mise j>roc - The misc^proc is called when Vera starts and when it transfers control back and forth with 
the HDL. This procedure is discussed in Section 153, "Handling Special Events.** ■ 
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data - The argument data is passed to the UDF call. It must be an integer. 
comment - The comment can be any user comment 

The Vera UDF Table is loaded dynamically at runtime from the library veraJtocaLdL 

15.3.2 Object Files and verajocal.dl for Verilog 

The verajtocaldl file is a dynamic library file that you must manually generate when you create your 
UDF object files. There are two steps you must take to create the veraJocalAl file: 

1 . Compile verajuser. c and all your library files with the appropriate position independent code options to 
create the verajocaldl file. 

2. Link the verajocaldl file with the necessary object files and libraries. 
This process is platform-specific. 



HPUX 

To create the verajocaldl file with object files: 

cc -c +2 -I$VERA_HOME/lib c_ files vera_user.c 
OR 

jp gec -fpic -I$VERA_HOME/lib c^files vera.user.c 

E-.iL 

^ cjiles - The cjiles are the UDF files you are linking with Vera, 

Uf After compiling verajuserc, link the verajtocaldl file with the necessary object files: 

§ \ 

Id -b +e eyssci_prod_entry + errno -o vera_local . dl o_ files \ 
vera_user.o vera.kernel -1c 

oJUes - The ojiles are the compiled UDF object files. 
Solaris 

To create the verajocaldl file with object files: 

cc -K pic -c -I$VERA_HOME/lib c_files vera_use*r.c 

OR 

gec -fpic -c -I. -I$VERA_HOME/lib affiles vera_user. c 
cjiles - The cjiles are the UDF files you are linking with Vera. 
After compiling verajusenc, link the verajocaldl file with the necessary object files: 

Id -G -Bsymbolic -o /vera_local.dl affiles v vera_user.o vera_kernel \ 
-lsocketi^lnsl.;rlintl.:rlc o^:? ^ tJ ~ : , ; _ % v^ ;; ^- ... 
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o Jiles - The o Jiles are the compiled UDF object files. 
SunOS 

To create the verajocaidl file with object files: 

cc -c -I$VERA_HOME/lib c^files vera_user.c 
c Jiles - The c Jiles are the UDF files you are linking with Vera. 
After compiling verajuser.c* link the verajocaidl file with the necessary object files: 

Id -o vera_local.dl o^files vera_user.o vera_kerael 
o Jiles - The o Jiles are the compiled UDF object files. 

q 15.3.3 Object Files and vera_mti.dl for VHDL 

The vera_mtudl file is a dynamic library file that you must manually generate when you create your 
01 UDF object files. There are two steps you must take to create the verajocaidl file: 

jj 1. Compile vera_user.c and all your library files with the appropriate petition independent code options to 

01 create the verajocaidl file. 

2. Link the verajocaidl file with the necessary object files and libraries. 
tl This process is platform-specific. , 

ni hpux 

=f To create the vera_mti.dl file with object files: 

cc +z -I$\TOUV w HOME/lib c_£iles vera.user.c 

OR 

gcc -fpic - I$VERA^HOME/ lib c^files vera_user.c < 

e Jiles - The c Jiles are the UDF files you are linking with Vera. 

After compiling vcrajuserx, link the vera_mtldl file with the necessary object files: 

Id -b +e syssci_prod_entry + errno -o verajnti.dl o_files A 
vera_user -o vera_kernel_jnti -lc 

o Jiles - The ojiles are the compiled UDF object files. 

Solaris - f; . , . ( . x . 

To create the vera_mxidl file with object files: 

cc -K pic -c -l$VERA^HOME/lib c^files vera_user.c 

— - ^Pr 
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OR 

gcc -fpic -c -I. -I$VERA_ HOME/ lib c^files vera.user.c 
cjiles - The cjiles are the UDF files you are linking with Vera. 
After compiling vera_usenc, link the verajmtLdl file with the necessary object files: 

Id -G -Bsymbolic -o vera_mti.dl o_ files vera_user.o vera_kernel.jnti \ 
-lsocket -Insl -lintl -lc 

ojiles - The ojiles are the compiled UDF object files, 
SunOS 

To create the verajmtLdl file with object files: 

cc -c - 1 $ VERA_HOME /lib c_ files vera_user.c 
cjiles - The cjiles are the UDF files you are linking with Vera. 
After compiling verdjuseKc* link the verajmtLdl file with the necessary object files: 

Id -o vera_mti.dl o_ files vera_user.o vera_kernel_mti 
ojiles - The ojiles are the compiled UDF object files. 

15,4 PLI Support Procedures 

Vera provides several procedures designed for PLI support. 
vera_num_argO 

The vera_num_argO system function returns the number of arguments in the UDF that it is called in. 
The syntax is: 

Tera_ntim_trg ( ) ; 

vera_get_argO 

The vera_get_argO system function returns a Vera data structure with the values in the specified argu- 
ment The syntax is: 

vera g«t_*rg ( index) ; 

index - The index is an integer that specifies which data structure to return. 

The function returns the data structure associated with the specified argument The values returned 
should be used without any modifications. You can free it manually or by calling vera_free_argO- 
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vera_free_arg() 

The vera_free_argO system function frees a Vera data structure returned by vera_get_arg(). The syn- 
tax is: 

vera_f ree_arg ( vera_da ta ) ; 
verajdata - Verajdata is a pointer to the data structure you want to free. 

When vera_free_argO is called, it frees all memory allocated by vera_get_argO, including bit and 
string data. 

vera_retum_value() 

The vera_return_valueO system function sets the return value for the UDR The syntax is: 

vera_return_volue ( veranda ta ) ; 

verajdata - Verajdata is a pointer to the data structure you want to return a value from. 

The vera_return_valueO system function returns the value associated with the specified data structure. 
It may be called only one time before returning. 

Note - Calling vera_return_valueO multiple times before returning may 
cause a crash. 



vera_put_argO 

The vera jut.argO system function sets the return value for a var argument The syntax is: 

vera_put_arg ( index, vera_data) ; 
int - The index specifies which argument is assigned a value. 

verajdata - Verajdata is a pointer to the data structure containing the value to be assigned. 

When the vera_put_argO system function is called, it assigns the value associated with the given data 
structure to the specified argument 

15.5 Handling Special Events 

When an HDL and Vera start or reset, your C functions may need to perform certain operations before 
they are ready to be used. Also, they may need to know when Vera and the HDL are passing control 
back and forth. To handle these events, you can write miscellaneous functions, which you call in the 
Vera UDF Table (see Section 15.3.1, "Vera UDF Table"). 
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When one of the predefined reasons occurs, the miscellaneous routine is called. Along with the data pa- 
rameter, it transfers a parameter to the function call that is based on why the routine was called. Table 
15-2 lists the VERA_REASONS and their values. 

TabU 15-2 VERA_REASON Values 



VERA_REASON 


Value 


VERA_REASON_INIT 


1 


VERA_REASON_RESET 


2 


VERA_REASON_RESDME 


3 


VERA_REASON_SUSPEND 


4 


VERA_REASON_EXIT 


5 



This function can be used to handle special events or set conditions necessary before UDF calls can be 
made. 
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Example 9: User-Defined Functions 

This is an example of UDF usage. This example covers the following constructs: 

• UDF code 

• UDF call from Vera 

• RUN script 

This example includes these files: 

• udfcodex 

• test.vr 

• RUN (a run script) 

udfcodex 

# include <stdio.h> 

# include 'vera_user .h* 

/* task $upctask( integer i, string strl, var string str2); */ 

int upctask(int data) 
{ 

int nargs = vera_nunuarg { ) , i ; 
vera_data *argl, *arg2 ( *arg3; 
vera_data retval; 

char *procn = "upctask', *strl, *str2; 
if (nargs != 3) 

{ ' 

fprintf (stderr, -upctask: Wrong number of args (%d)\n', nargs); 

exit(l); 

) 

argl = vera_get_arg(0) ; 
arg2 = vera_get_arg ( 1 ) ; 
arg3 = vera_get_arg (2 ) ; 
if (argl->type 3= VERA_INT) 
{ 

fprintf (stderr, 'upctask: 1st arg is not an integer\n - ); 
exit(l); 

) 

if (arg2->type != VERA_STRING) 
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fprintf (stderr, 'upctask: 1st arg is not a string\n*); 
exit(l); 

} 

if (arg3->type 1= VERA_STRING) 
{ 

fprintf (stderr, "upctask: 1st arg is not a stringVn'); 
exit(l) ; 

} 

i = argl->data.int_val; 
strl = arg2 ->data. string ; 
str2 = arg3->data. string; 

fprintf (stderr, "task %s: i=%d strl='%s' str2='%s' \n" , procn, i, 
strl, str2); 
retval . type = VERA_STRING ; 
re tval. data. string = 'arg task, task"; 
vera_put_arg ( 2 , tretval ) ; 
vera_free_arg(argl) ; 
vera_free_arg(arg2) ; 
vera_f ree_arg (arg3 ) 

} 

/* function string $upcfunc (integer i, string strl, var string str2); */ 
int upcfunc(int data) 

{ 

int nargs = vera_num_arg ( ) , i ; 
vera_data *argl, *arg2, *arg3; 
vera_data retval ; 

char * procn = "upcfunc", *strl, *str2; 

if (nargs != 3) 
{ 

fprintf (stderr, *upcfunc: Wrong number of args (%d)\n", nargs); 
exit(l); 

} 

argl = vera_get_arg ( 0 ) ; 
arg 2 = vera_ge t_arg ( 1 ) ; 
arg3 = vera_get_arg(2) ; 
if ( argl- > type != VERA_INT) 
{ 

fprintf (stderr, "upcfunc: 1st arg is not an integer\n" ) ; 
exit(l); 

} 

if (arg2->type ! = VERA^STRING) 

{ -;.••:>.■;■ ...... . > f; , .. . z 

fprintf (stderr, 'upcfunc: 1st arg is not a stringXn"); 
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exit(l); 

} 

if (arg3->type != VERA_STRING) 
{ 

fprintf (stderr, "upcfunc: 1st arg is not a string\n"); 
exit (1) ; 

} 

i = argl->data.int_val; 
strl = arg2->data. string; 
str2 = arg3->data. string; 

fprintf (stderr, "func %s: i=%d strl='%s' str2=' %s' \n" , procn, i, strl, 
str2) ; 

retval . type = VERA_STRING; 
retval. data. string = "arg func, func"; 
vera_put_arg ( 2 # &r etval ) ; 
retval. data. string = 'ret func, f unco- 
ver a_return_value ( &re tval ) ; 
vera_f ree_arg (argl ) ; 
vera_free_arg(arg2) ; 
vera_free_arg(arg3) ; 

) 

/* misc procedure calls */ 

int upcmiscKint reason, int data) 
{ 

printf ( "upcmiscl called with data=%d and reason=" , data) ; 

switch (reason) 

{ 

case VERA_REASON_INIT : printf ( • VERA_REASON_INIT\n* ) ; break; 
case VERA_REASON_RESET: printf ( ' VERA_REASON_RESET \n • ) ; break; 
case VERA^REASON.RESUME: printf ( "VEIU^REASONJRESDMEXn* ) ; break; 
case VERA_REASON_SUSPEND:printf ( • VERA_REAS ON_SUS PEND \ n • ) ; break; 
case VERALREASON_EXIT : printf CVERA^REASON^EXITVn' ) : ; break; 
default: printf C????????????????\n*) * fereak; 



} 



} 



int upcmisc2 (int reason, int data) 
{ 

printf Cupcmisc2 called with data-%d and reasons" ,data) ; 
switch (reason) 



{ 



case VERA^REASON_INIT : printf ( " VERA_REASON_INIT \n 9 ) ; break; 
case VERA w REASON_££SET: printf ( "VERA^JlEASONLRESETXn" ) ; ■ break; 
case VERAJEASONJESOME: printf (*VERA,REASONJRESUME\n^; Jgjfeak; 
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case VERA_REASON — SUSPEND : print f ( *VERA_REASON_SUSPEND\n" ) ; break; 
case VERA_REASON_EXIT: print f rVERA_REASON_EXIT\n« ) ; break; 
default: printf C????????????????\n") ; break; 

} 

) 



test.vr 

#include <vera__def ines . vrh> 

task $upctask( integer i, string strl, var string str2) ; 

function string $upcfunc (integer i, string strl, var string str2) ; 

program test 
{ 

string a, b # c; 

a = 'I am a'; 

b = -I am b"; 

c = "I am c*; 

$upctask(l, "I am here*,c); 

printf Ca='%s' b='%s' c='%s'\n',a,b,c) ; 

c = $upcfunc(l,a,b) ; 

printf Ca='%s' b='%s' c= ' %s ' \n- , a,b, c) ; 

} 



RUN 



#»/bin/csh -f 
ff I /bin/csh -fxv 

set ARCH = Vusr/local/bin/ncpu' 
echo $VERA_HOME 

™ -rf vera_user.h vera_user.c vera_kernel libVERA.a vera_cs_local \ 
vera_local,dl vera_user.o udfcode.o test.vro simv simv.daidir \ 
verilog.log >& /dev/null 

cp $VERA_HOME/lib/{vera_user.h,vera_user.c, vera_kernel, libVERA.a} . 
sed -e '/\/\* user entries go here \*\//s/~. *$/#include 'udf.c'/'N 
vera_user.c > temp 

rm -f vera_user.c 

cat - temp > vera_user.c «END 

# include <stdio.h> . 
# include .•udf .h* 

"END " ""'•'•^ ■•.-•..'•:-* . r;.V:- ; . . v. . .■ . 
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rm -f temp vera_local .dl 
set csrc = (vera.user.c udfcode.c) 
set cos = (vera.user.o udfcode.o) 
setenv SSI_LIB_FILES . / vera_local . dl 
vera -crop test .vr 
if ($status) exit 1 
switch ($ARCH) 
case "SOL - : 

cc -DNO_VERILOG_SIM -K pic -c $csrc |& egrep -v ,A vera_user.c:$ | \ 
Udfcode.c: $' 

Id -G -Bsyinbolic -o vera_local .dl $cos vera_kernel -lsocket -lnsl \ 
-lintl -lc 

cc - DNO_VERI LOG_S IM -o vera_cs_local $csrc libVERA.a -lsocket -lnsl\ 
-lintl -lm |€c egrep -v ' A vera_user.c:$ | ^udfcode.c: $' 

vcs -q test.vshell -1 vcs.log -P $VERA_HOME/lib/vera_j?li. tab \ 
$VERA_HOME/lib/libSysSciTaskpic.a >& /dev/null 

if ($status) exit 1 

breaksw 

case *SUN4': 

gcc -DNO_VERILOG_SIM -fpic -c $csrc 
Id -o vera_local . dl $cos vera_kernel 
chmod +w libVERA.a 
ranlib libVERA.a 

gcc -DNO_VERILOG_SIM -o vera_cs_local $csrc libVERA.a -lm 
vcs -q test.vshell -1 vcs.log -P \ , 

$VERA^HOME/lib/vera_pli.tab $VERA_HOME/lib/libSysSciTask.a \ 

>& /dev/null 
if ($status) exit 1 
breaksw 

case •HPUX-10' : 

gcc -DNO_VERILOG_SIM -fpic -c $csrc 

Id -b +e syssci_procUentry +e errno -o vera_local . dl \ 
$cos vera_kernel -lc -lm 

gcc -DNO_VERILOG_SIM -o vera_cs_local $csrc libVERA.a -lm 

vcs -q test.vshell -1 vcs.log -Mupdate=l -gen_c -P \ 

$VERA ta _HOME/lib/vera_pli.tab $VERA_HOME/lib/libSysSciTaskpic.a \ 
-LD FLAGS --E -a archive_shared - -ldld >& /dev/null 

if ($status) exit 1 

breaksw 

endsw 
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vera -cmp test.vr 

if ($status) exit 1 

. /vera_cs_local test.vro 

verilog test.vshell -1 verilog.log +vera_load=test .vxo 
. /siinv +vera_load=test . vro 

nn -rf vera_user.h vera_user.c vera_kernel libVERA.a vera_cs_local \ 
vera_local.dl vera.user.o udfcode.o test.vro sintv simv.daidir >& \ 
/dev/null 
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16. VERA-SV API 

This chapter introduces Vera-SV API, which is used for hardware/software co-verification and 
distributed simulation. It includes these sections: 

• Vera-SV Motivations 

• Vera-SV Overview 

• The Vera Side 

• The C/C++ Side 

• Troubleshooting 

• Backward Compatibility 

16.1 Vera-SV Motivations 

The key motivations behind the development of Vera-SV are hardware/software co-verifica- 
tion, distributed simulations, and a master-slave configuration where the C side controls the 
simulation. 

16.1.1 Hardware/Software Co-Verification 

HW /SW co-verification involves the concurrent development of software and hardware. In 
this methodology, software components (drivers/debuggers, appUcation programs) are com- 
piled to run at full speed on a workstation and interact in a bus-cycle accurate fashion with a 
simulated hardware model. • 

This API supports HW/SW co-verification by enabling C/C++ applications (eg. drivers, de- 
buggers, appUcation programs) and Vera programs to execute remote calls to each other. 
C/C++ appUcations are compiled into native binary executables and run on the host worksta- 
tion at full speed. They use the API to interact with hardware models (Verilog, VHDL, Q run- 
ning under the control of a Vera program. 

With the API, C/C++ appUcations call tasks and functions in the Vera program which then 
probe, stimulate, and monitor the hardware model. In a similar fashion, the Vera program can 
react to an event generated by the hardware model and call the C/C++ appUcation to notify it 
of ah asynchronous event (like an interrupt, for instance). 



Synopsys Inc. 



# m 

294 ChapteMS, VERA-SV API Vera 4.0 User's Manual 

16.1.2 Distributed Simulation 

Distributed simulation is often used with, but not limited to, HW/SW co-verification. Distrib- 
uted simulation involves verifying large designs by partitioning verification tasks to run con- 
currently across multiple processors. This API supports distributed simulation by enabling 
multiple Vera programs and C/C++ applications to execute remote calls to each other across a 
network of workstations. For example, an application program on one host can be executing 
assembly code for a particular processor and interacting via the API with Vera programs on 
another host that simulate the board containing the processor. 

Note - Both UNIX and NT workstations are supported. 



16.1.3 Master-Slave Configuration 

The traditional and default setup for Vera/C interfaces has Vera as the master. In this setup, 
Vera controls the simulation time and determines how the calls to C are made. However 
sometimes it is useful to have the C side control the simulation completely and dictate the 
simulation time along with all simulation activity Vera-SV provides the flexibility for such a 
setup. 

16.2 Vera-SV Overview 

The Vera System Verifier API is a collection of predefined Vera functions and a C program- 
mer's library. Together, they enable the development of hardware and software co-verification 
and distributed simulation environments. 

With this API, verification engineers can build interfaces between system components mod- 
eled with Vera and C/C++. This API enables Vera programs to communicate and synchronize 
with other Vera programs and with independent C/C++ applications via remote calls. 

The API's remote call technology permits a natural way to model system components: 

• Remote calls initiated from Vera programs 'are inherently multi-threaded (Vera threads, not 
UNIX/NT threads). This allows your hardware models to mimic the concurrency of real hard- 
ware. For example, a Vera program can have multiple tasks waiting concurrently for their 
remote calls to execute- While these suspended tasks are waiting, other Vera tasks will continue 
their execution. 

• Remote calls from a client to a server may be either blocking or non-blocking. Blocking c?H<= 
have an implicit handshake; they wait for the server to execute the call before returning. Non- 
blocking calls are equivalent to message passing; they send the call to the server and return 
immediately (possibly before the server has a chance to execute the call). 

• The remote call mechanism is efficiently passes large chunks of data between simulations. 
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The API creates point-to-point (1-to-l) connections. A connection consists of a server/client 
pair; the server is on one side of the connection; the client is on the other. A single process may 
create both client and server connections, but it must not connect to itself. 

A single process may also create multiple server and client connections, but each server con- 
nects to exactly one client, and each client connects to exactly one server. 

Using the API is straight-forward and consists of these three basic steps: 

1. Define a network of server/client, Le., components which will talk to each other. 

2. Bring up the servers /clients network. 

3. Execute the remote calls. 

16.3 The Vera Side 

This section describes how to make remote calls from Vera programs to other Vera programs. 
All connections between the Vera programs need to be defined and brought up before remote 
calls are made. The Vera functions that define the network of connections are 
vsv_make_serverO and vsv_make_clientO- 

16.3.1 Initializing Connections 

Vera has a set of functions used to initialize connections. 
vsv_make_server() and vsv_make_client() 

Vera provides the system functions vsv_make_serverO and vsv_make_clientO to initialize 
connections. The syntax is: 

v«v_mak«_«erver (port , authentication [, verbose]); 
v«v_ma)ce_cli©nt<*host-, port, authentication); 

port - The port indicates a virtual port nunrvber used for a single client/server pair during a 
session. It can be any positive integer, 

authentication - The authentication specifies an authentication code to use while bringing up 
connections. If the server specifies a zero value, no authentication is needed for the 
connection, and the value provided by the client is discarded. If the server authentication 
is not zero, the client and server authentications must match. 

verbose - The verbose modifier can be omitted or VERBOSE. If it is set, the server outputs 
messages if errors occur while processing remote client submissions. 

host - The host is a string that specifies the IP address or host name of the server. 
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Both these functions return a non-zero integer identifier that is used for the subsequent use of 
the connection. A returned zero-value means the function failed and the connection has not 
been set up. 

Each call to vsv_make_serverO must be matched by one and only one call to 
vsv_make_clientO in another Vera simulation. 

This is an example of the vsv_make__server() and make.hostO system functions: 
integer servconn; 

servconn = vsv_make_ server (5555, 0, VERBOSE); 
integer clientl, client2; 

clientl = vsv_make_client ( m localhost* , 5555, 0); 
client2 = vsv_make_client ('171.64 .195.82', 7777, 0) ; 

This example creates two clients for the host. The authentications for each client are 0, which 
matches the server authentication. Each client/server pair is opened on a separate port. 

vsv_up_connections() 

Once all connections have been configured, the vsv_up_connections0 system function is used 
to make all of them active. The syntax is: 

vsv_up_connectionfl ( timeout) ; 

timeout - The timeout specifies the time limit allowed to bring up connections. It is specified in 
seconds per connection. 

The function returns 0 if all connections have been activated or -1 otherwise. The 
vsv_up_connections0 system function can only be called once in each simulation. If it fails, 
none of the connections made by vsv_make_clientO or vsv_make_server() are usable, and you 
need to re-start the simulations if you want to use the Vera-SV APL 

After a successful activation,' the connections are ready to process and/or submit remote calls. 
This is an example of the vsv_up_connections0 system function: 
vs v_up_connec t i ons ( 3 0 ) ; 

v. 

In this example, if the Vera program has previously configured a server and a client connec- 
tion, vsv_up_connections(30) times out after 60 seconds. 

■ * * ■ »■ 

vsv_close_conn() 

Connections can be closed with the vsv_close_conn0 system function. The syntax is: 
w_doi«_coan ( connec ti on ) ; 

connection - The connection specifies which connection to close. It is the integer identifier 
passed by vsv_make_serverO when the connection is created. 
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This function return -1 if an error occurs, otherwise returns zero. 
This is an example of the vsv_close_conn() system function: 

myconn=vsv_make_client ( •lo.calhost* , 5555 , 0 ) ; 
vsv_close_conn (myconn) ; 

16,3-2 Servicing Remote Calls 

When a Vera program is a server, all global Vera task and functions are available as remote 
procedures to the client, and servicing remote calls is transparent At the end of every cycle, 
the Vera simulation engine will process arriving remote calls. The remote calls will then be dis- 
patched to the tasks and functions in the Vera program. When these tasks and functions com- 
plete, their returned values and VAR parameters are automatically sent back to the client. 

Remote calls run simultaneously with the main Vera application. It is up to the user to syn- 
chronize the remote calls with the main execution if necessary. 

16.3.3 Submitting Remote Calls 

These are the two system functions which can submit calls from a Vera program to a remote 
application: vsv.callJuncO and vsv.calLtaskO. The syntax to call them is: 

V8v_call_:fTinc (connection, time_mode, funcjname, return_value [, opt_args] ) ; 

vav_call_t:aolc( connect ion, time_mode, tasK_name I, opt_args] ) ; 

connection - The connection is the connection identifier returned by vsv_make_clientO. 

timejmode - The timejmode must be WAIT, which suspends simulation time until the call is 
completed, or NO_WAIT, which allows the simulation time to advance while the call is in 
execution. 

funcjnatndtoskjnatne - The funcjname or taskjname is a string with the name of the remote 
procedure to be executed. " " v 

' returnjoalue - The returnjoalue must be a variable (not an expression) that matches tKe type 
returned by the remote function! The returnjoalue can be of type integer; bit vector; or 
string. The value of the variable is set by the remote function calL 

opt_arg$ - The optjargs are optional arguments that must match the corresponding 

arguments on the function or task side. The optjirgs can be of type integer, bit vector; 
or string. They can be variables if the remote argument specifies a var argument, or 
expressions if the remote argument is not of type var. 

These are examples that illustrate valid uses of arguments: 

Remote prototype Valid local calls 



Synbpsys trie; 



'Hi 



298 Chapter 1 6. VERA-S V API Vera 4.0 User's Manual 



integer result, c # i[10); 
string mystr; 
bit [5:0] r; 

INTEGER factorial (NONVAR/ INTEGER) vsv_call_f unc ( . . . factorial , result , 5 ) 

vsv_call_f unc ( factorial , result , i [ 5 ] ) 
vsv_call_func < . . . factorial, result, c) 

printValue ( NONVAR/ STRING NONVAR/BIT ) vsv_call_task < . . .printValue, *foo',2'bxl) 

vsv_call_task(. . . printValue mys tr , r) 

myfoo ( VAR/ STRING VAR/ INTEGER ) vsv_call_task ( . . .myf oo, mystr, c) 

The vsv_call_funcO and vsv_calljask0 system functions suspend the calling Vera thread un- 
til the call has completed. Other Vera threads that are not suspended can continue to run, as 
long as they do not advance simulation time. Both vsv_call_funcO and vsv_call_taskO return 
a value of 0 on successful completion and a non-zero value otherwise. 

This is an example of the vsv_call_func() and vsv_call_task0 system functions: 

integer result; 
integer myconn; 
bit [7:0] b = 8 'bxxxOOOzz ; 

myconn = vsv_make_client ( 'localhosf , 3333, 0, VERBOSE); 
vsv_up_connections () ; 

if (vsv_call_f unc (myconn, NO_WAIT, 'factorial*, result, 5) != 0) 
printf ( 'Error in factorial call: %s\n* , vsv_get_conn_err ( ) ; 

if <vsv_call_task (myconn, WAIT, 'printValue*, 'Bitvalue*, b) != 0) 
print f ( "Error in printValue call : %s \n* , vsv_get_conn_err ( ) ; 

16.3.4 Managing errors 

When any of the API functions return an error value, the vsv_get_conn_err0 function can be 
called to obtain a message describing the cause of the failure. The syntax is: 

v«v_aet_conn_err ( ) ; . 

The vsv_get_conn_err0 returns a message describing the cause of the failure. Possible reasons 
of failure are a: dropped connection, mismatched authentication, mismatched task/function 
prototype, etc 

This is an example of the vsv_get_conn_errO system function; 

if (vsv_call_task(conn, N0_WAIT, 'myfoo*, mystr, c) 1 != 0) 
printf ( 'Error in myfoo call: %s\n*, vsv_get_conn_err () ) ; 
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16.3.5 Master-Slave Configuration 

Vera-SV provides the vsv_wait_f or_inputO and vsv_wait_for_doneO system tasks to facilitate 
the use of Vera in a Master-Slave environment where Vera is the slave (server) and a C/C++ 
process is the master (client). 

vsv_walt_forJnput() 

The vsv_wait_for_inputO system task suspends the current Vera thread until a remote client 
function request is received. The syntax is: . * 

vev_wait_£or_inimt ( urai t_mode) ; 

waitjmode - The waitjmode can be WAIT, which suspends both the Vera thread and the 
simulation time until a remote client function request is received, or NO_WAIT, which 
allows other Vera threads to increment the simulation time as necessary. 

When the vsv_wait_f or_input() system task is called, the current Vera thread is suspended. If 
the wait mode is set to WAIT, the simulation time is also suspended. All Vera threads waiting 
for the simulation time to advance are suspended as well. However; if the wait mode is set to 
NO_WAIT, other concurrent Vera threads continue to execute and advance simulation time. 
As soon as a remote client function request is received, the thread resumes execution- If there 
are already remote calls being processed at the time the call is made, the task does not sus- 
pend the Vera thread. 

vsv_waft_for_done() 

The vsv_wait_for_doneO system task suspends the current thread until all of the remote client 
calls have been completely processed and the replies returned. The syntax is: 

v«v_wait_f or_done < ) ; 

As soon as replies have been returned to the client, the thread resumes execution. 



Note - The remote client call is considered to have completed when a 
reply is returned, even if background Vera threads that were created 
by the remote call are still active 

This is an example of the vsv_wait_for_inputO and vsv_wait_for_done6 system tasks: 

repeat (3) 
{ 

vsv_wait__for_ input (WAIT) ; r 
vsv_wait_f or_done ( ) ; 

} 



300 Chapter 16. VERA-SVAPI 



Vera 4.0 User's Manual 



This example suspends the current thread and the simulation time until a remote call is re- 
ceived. The requested function is executed, and simulation time is advanced during that exe- 
cution as necessary. Then the thread suspends until the next call is made. This cycle is 
repeated three times. 

16.3.6 Separate Client and Server Example 

This example demonstrates how one Vera program calls a function in another Vera program. A 
program running on a host named "rige!" calls the "multiply" function in a program running 
on "cetT. 

Program Running on Host "ceti" 

# include <vera_de fines . vrh> 

program ceti 
{ 

event rigel_called_me; 
integer connection; 

// the program running on rigel will call this 

function integer multiply (integer a, integer b) 
{ 

multiply = a * b; 

trigger (ONE_BLAST, rigel_called_me) ; 
} * 

// make this program a server 

connection = vs v_make_s erver (2222,0, VERBOSE ) ; 
if (connection == 0) 

error ( *vsv_make_s erver failure \n*); 
i f ( vs v_up_connec t ions (30)) 

error ( m vsv_up_conhections f ailure\n* ) ; 

// wait for rigel to call me 1 
sync (ALL, rigel_called_jne) ; 
printf(*ceti is done\n'); 
vsv_close_conn (connection) ; 

} 

Program Running on Host "rigel" 

# inc lude < ve r a_de f ines . vrh> 

program rigel 
{ 

integer connection; 
integer product; 
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// make this program a client 

connection = vsv_make_client ( *ceti* , 2222 , 0) ; 
if (connection ==0). 

error ( *vsv_jnake_client failure \n* ) ; 
if (vsv_up_connections (30) ) 

error (~vs v_up_ connect ions failure\n*); 

// have remote host multiply 3x7 

if (vsv_call_func (connection, WAIT, "multiply- , product, 3, 7)) 

error (*vsv_call_func failure\n'); 
printf( m 3 * 7 = %d\n*, product); 
vsv_close_conn( connection) ; 

) 

16.3.7 Combination Client-Servers Example 

This example demonstrates how two Vera programs can call each other. Each Vera program 
operates as both a client and a server. 

One program runs on a host named "ceti"; one on a host named "rigel". Both programs initial- 
ize a local semaphore to be empty and fork a thread to wait on that semaphore. Each program 
then calls a remote task in the other program to unlock the semaphore for the other program. 

Program Running on "ceti" 

# include <vera_def ines .vrh> 

program ceti 
{ 

integer server, client; 
integer semaphore_id; 

//the program running on rigel will call this task 
task ceti_unlock< integer semaphore_value) 
{ 

printf ( m rigel unlocked me\n* ) ; 
seinaphorejut(semaphore_id, semaphore_value) ; 

// initialize my semaphore to empty 

semaphore_id = alloc (SEMAPHORE, 0, 1, Ob- 
server = vsv_make_server (2222,0, VERBOSE) ; 
if (server == 0) 

error ( * vsv_make_server failure \n* ) ; 
client = vsv_make_client ( -rigel', 3333, 0) ; 
if (client ~ 0) 

error ( -vsv_make_client failure\n'); 
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if (vsv_up_connections (30) ) 

error ( * vsv_up_connections f ailure\n* ) ; 
fork 
{ 

// unlock rigel 

if (vsv__call_ task (client, NO_WAIT, *rigel_unlock* , 1) ■ = 0) 
error ( *unlock on rigel failure\n*) ; 

} 
{ 

// wait for rigel to unlock me 

semaphore_get (WAIT, semaphore_id, 1 ) ; 

} 

join 

printf(*ceti is done\n*); 
vsv_close_conn ( server) ; 
vsv_close_conn ( client ) ; 



Program Running on "riger 

# include <vera_de fines . vrh> 

program rigel 
{ 

integer server, client; 
integer semaphore_id; 

// the program running on ceti will call this task 
task rigel_unlock (integer semaphore_value) 
{ 

printf(*ceti unlocked me\n*); 
s emaphore_pu t ( s emaphor e_i d , s emapho r e_va lue ) ; 

} 

// initialize my semaphore to empty 

semaphore_id = alloc (SEMAPHORE, 0, 1, 0) ; 
server = vsv_make_server (3333 , 0, VERBOSE) ; 
if (server == 0) 

error ( m vsv_make_server failure\n'); 
client = vsv_make_client( m ceti*, 2222,0) ; 
if (client ==0) 

error ( m vsv_make_client failure\n*) ; 
if (vsv_up_connections(30) ) 

error ( *vsv_up_connections f ailureXn* ) ; 
fork ^ 
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{ 

// unlock ceti 

if <vsv_call_task (client, NO_WAIT, *ceti_unlock* , 1) != 0) 
error ( 'unlock on ceti failure\n*); . 

} 
{ 

// wait for ceti to unlock me 

semaphore_get(WAIT, semaphore_id, 1) ; 

) 

join 

printf (*rigel is done\n*); 
vsv_close_conn ( server) ; 
vsv_close„conn (client) ; 



16.4 The C/C++ Side 

This section describes how to make remote calls between' C/C++ applications and Vera pro- 
grams. All connections between the C/C++ applications and Vera programs need to be de- 
fined and brought up before remote calls are made. 

The API procedures for C/C++ applications are similar to their Vera counterparts, and only 
their prototypes are described in this document 

For a complete description of the API procedures please see the "$VERA_HOME/lib/vsv.h" 
file. 

These are the prototypes: 

extern void *vsv_tfakeServer ( 
int port, 

int authentication 
); 

extern void *vsv_JiakeClient ( 
char *host, 
int port, 
"int authentication 
); 

extern int vsv_UpConnections ( 
int timeout 

); • . • -•■ 

extern int vsv_CallFunc ( 

void *connection, 

char *name, 

vsvArgT *returnVal, 

int number Args , 

vsvArgT *args ... 

); 

extern int vsv_CallTask ( - ; » 

void * connection , 

char *name, — - 
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vsvCallWaitingT wait, 

int numberArgs , 

vsvArgT *args 

); 

extern int vsv_CloseConn ( 
void *connection 
); 

extern char *vsv_GetErrorMesg (void) ; 

In addition to the above, the API also provides procedures for C/C++ applications that will 
function as servers. C/C++ servers need to p re-register functions and tasks that will be made 
available to clients by calling vsv_RegisterFunc and vsv_RegisterTask API procedures. Also, 
C/C++ servers must explicitly call vsv_AnswerCalls to service incoming function and task 
calls from the clients. 



Note - This is not true if the application is both a server and a client, 
in which case incoming calls will be automatically serviced if the 
application is waiting for a vsv_CallFunc or vsv_CallTask to 
complete. Here are the API prototypes foir servers: 



extern int vsv__RegisterFunc (. 

void *connection, 
char *name, 
vsvArgT *returnVal, 
int numberArgs , 

vsvArgT *args , 

vsvFuncCbT fcb 
); 

extern int vsv_RegisterTask ( 

void *connection, 

char *name , 

int numberArgs , 

vsvArgT *args, 

vsvTaskCbT tcb 

); 

extern int vsv_AnswerCalls ( 

void * connection, 

vsvCal lHandl ingT how 

); 

16.4.1 . Calling a Vera Task from a Oprogram Example 

This example demonstrates how a C-program running on host named ^ceti" calls a task in a 
Vera program running on a host named "rigel". 

C Program Running on "cetT 

♦include <vsv.h> 

• ~- • 
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mainO 
{ 

vsvArgT arg; 
void * connection; 

/* make this program a client of rigel */ 

connection = vsv_MakeClient (*rigel* , 2222 , 0) ; 
if (connection == NULL) 

per r or ( vsv_GetErrorMesg { ) ) ; 
if (vsv_UpConnections (30) ) 

perror ( vsv_GetErrorMesg ( ) ) ; 

/* call the remote task passing an integer argument set to 1 
arg.vtype = VSV _#ONVAR_ARG; 
arg.dtype = VSV_INTEGER_ARG ; 
C3 arg.data.integerVal = 1; 

*D if (vsv_CallTask (connection, •unlock*, VSV_WAIT, 1, targ) ) 

2* perror ( vsv_GetErrorMesg ());■' 

'■zl (void)printf (*ceti is done\n'); 

Zl (void) vsv_CloseConn( connection) ; 

55 exit (0) ; 

w } 

s 



p Vera Program Running on "rigeP 

# include <vera_def ines . vrh> 

program rigel 
{ 

integer connection; 
integer semaphore_id; 



// the program running on ceti will call this task 
task unlock (integer semaphore_value) 
{ 

printf( m ceti unlocked me\n*); 

semaphore_put (semaphore_id, semaphore_value) ; 

// initialize my semaphore to empty 

semaphore_id = alloc ( SEMAPHORE , 0, 1, 0) ; 

// make this program a server 

connection = vsv_make_server (2222,0, VERBOSE) ; 
if (connection == 0) 

error (*vsv_make_server failure\n*); 
if (vsv_up_connections (30) ) 

error ( *vsv_up_connec tions failure\n") ; 
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// wait for ceti to unlock me 

semaphore_get (WAIT, semaphore_id, 1); 
printf (*rigel is done\n*); 
vsv_close_conn (connection) ; 

} 

16.4.2 Calling a C Function from a Vera Program Example 

This example demonstrates how a Vera program running on host named "rigel" calls a func- 
tion in a C program running on a host named "ceti". 

Vera Program Running on "rigel" 

# include <vera_de fines . vrh> 

program rigel 

{ 

integer connection, product; 

// make this program a client 

connection = vsv_make_client ( "ceti* , 3333 , 0) ; 
if (connection ==0) 

error ( *vsv_make_client failure\n*) ; 
if (vsv_up_connections (30) ) 

error ( *vsv_up_connections f ailure\n* ) ; 

// call the remote multiply function on ceti 

if (vsv_call_func (connection, WAIT, 'multiply*, product, 8, 9)) 

error ( *vsv_call_f unc failure\n*); 
printf ( 'product = %d\n* , product); 
vs v_c 1 os e_conn( connect ion) ; 

} 

C Program Running on "ceti" 

# include <vsv.h> 
static int done = 0; 

static void multiply (vsvArgT *returnVal, int numberArgs, vsvArgT *args) 
{ 

/* set the return value */ 

returnVal-xiata. integerVal = 

args [0] .data. int egerVal * args [1] .data. integer Val; 
done = 1; 
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mainO 
{ 

vs vArgT re turnVal , args [ 2 ] ; 
void *connection; 

/* make this program a server */ 

connection = vsv_MakeServer (3333 , 0) ; 
if (connection == NULL) 

perror ( vsv_GetErrorMesg ( ) ) ; 

/* define the argument types accepted by the multiply function */ 
returnVal.vtype = VSV_VAK_ARG; 
returnVal.dtype = VSV.INTEGER^ARG ; 
argsCO] .vtype = VSV_NONVAR_ARG ; 
args [0] .dtype = VSV_INTEGER_ARG ; 
args [1} .vtype = VSV_NONVAR_ARG ; 
args [1] .dtype = VSV_INTEGER_ARG ; 

if (vsv_RegisterFunc (connection, -multiply* , treturnVal, 2 , args, multiply) ) 

perror (vsv_GetErrorMesg ( ) ) ; 
if (vsv_UpConnections(30) ) 

perror ( vsv_GetErrorMesg ( ) ) ; 

/* wait for multiply to be called once */ 
while (! done) 
{ 

if (vsv_AnswerCalls (connection, VSV_DO_PENDING) ) 

perror ( vsv_GetErrorMesg ( ) ) ; 
sleep (1) ; 

) 

(void) vsv_CloseConn (connection) ; 
exit(0) ; 

} 

16.5 Troubleshooting 

If the vsv_up_connectionsO system function is failing, use the VERBOSE option with 
vsv_make_serverO and make sure that zombie UNIX/NT processes are not still running from 
previous simulations. You may also want to increase the timeout parameter passed to 
vsv_up_connectionsO. 

If vsv_up_connectionsO works, but your network is slow and your remote calls are failing 
with errors such as "Connection timeout, no response* try setting these environment vari- 
ables: 

setenv VSV_READ_T IMEODT 600 
setenv VSV_BLOCKEEl.TIMEOUT 120 
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16.6 Backward Compatibility 

For backward compatibility, these system function names from previous versions of Vera are 
still in use with their corresponding current names: 

Table 16-1 Previous and Current VSV System Functions 



Previous 


Current 


call_f unc 


vs v_cal l_f unc 


call_task 


vs v_ca 1 l_tas k 


close_conn 


vs v_c 1 o s e_c onn 


get_conn_err 


vs v ge t_conn_er r 


make_client 


vs v_make_cl ient 


make_server 


vsv_make_ server 


up_c onnec t i ons 


vs v_up_connec t ions 



• 
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17. Testbench Setup and Usage Notes 

This chapter discusses general setup and usage notes for creating and running simulations with Vera 
testbenches. It includes these sections: 

• Creating Testbenches for Verilog Designs 

• Creating Testbenches for VHDL Designs 

• VHDL Testbench Usage Notes 

1 7.1 Creating Testbenches for Verilog Designs 

Hiis section discusses the creation of Vera testbenches using the Vera template generator. It also details 
how to connect Vera testbenches to Verilog designs through the test-top file and through direct connec- 
tions. Finally, it details how to set up multiple clocking domains. 

17.1.1 Vera Template Generator 

Vera's template generator creates a simulation framework and a Vera program template from an HDL 
module definition. The syntax to invoke the template generator is: 

vera -tern template^options HDL_filename 
template joptions - The tempkue^options are listed in Table 17-1. 
Table 17-1 Template Options 

Option Definition 



-c Specifies clock signal 

-d Specifies dump file 

-nav Uses Magellan for simulation control 

-t specifies Verilog module name 



HDL JUename - The HDLJilename is the HDL file from which the template is generated. 



-c 

The -c option specifies the clock signal on the HDL module. The syntax is: 



-c clocK_signal 

... clock^ignol - The clock^ignol is the signal you want to connect SystemClock to^ ^ 



— ^m* 
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When the -c option is invoked, the defined clock signal is connected to SystemClock, and it is spec- 
ified as CLOCK in the interface specification. If this option is omitted, SystemClock is used as the 
sampling clock. 

-d 

The -d option specifies the dump file name. The syntax is: 
-d filename 

filename - The filename is the name of the dump file, 
-nav 

The -nav option invokes Magellan for simulation control, source level debugging, and waveform dis- 
play. The syntax is: 

-nav 

To use Magellan or any other graphic package, you need the corresponding PLI tasks linked to your 
HDL executable. 

-t 

The -t option specifies the top HDL module name. The syntax is: 
-t filename 

filename - The filename is the name of the top HDL module from which the template is being 
generated. 

The -t option is mandatory. It is used to generate three output files: filename. test jiop.\, filename Af.vrh, 
and file name. vr.lmp. 



This is an example module from a Verilog model file sample.v: 

module myfsm(isig, osig, others, Clk) ; 

input isig; 

output osig; 

inout [3:0) others; 

input Clk; 

endmodule 

Given this Verilog model and module, this command line is invoked to generate a Vera template: 
vera -tern -t myfsm -c Clk -nav -d myf sm. dump sample.v . 

When the command line is invoked, this test top file myfsm, testjtop. v is generated, which contains the 
instances of vera_shell and the specified module with all signal connections: 
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module myf sm__test_top; 

parameter simulation_cycle = 100; 

reg SystemClock; 

wire isig; 

wire osig; 

wire [3:0] others; 

wire Clk; 

assign Clk = SystemClock; 

vera_shell vshell ( 

.SystemClock (SystemClock) , 

,myfsm_isig(isig) , 
.myf sm_osig (osig) , 
.myf sm_others (others) # 
.myfsm_Clk(Clk) 

); 

myf sm dut( 

.isig(isig), 
.osig (osig), 
. others (others ) , 
.Clk(Clk) 

) ; 

initial begin 

SystemClock = 0; 
forever begin 

# (simulation_cycle/2 ) 
SystemClock = -SystemClock; 

end 

end 

initial begin 

$dumpfile(*myfsm.dump - ) ; 
$dumpvars (0 , myf smites t_top) ; 

end 
endmodule 

Invoking the command line also generates the interface file myfsm.if.vrh: 

interface myfsm { 

output isig OUTPUT_EDGE OUTPUT_SKEW; 
input osig INPUT_EDGE; 

inout [3:0] Others INPOT.EDGE OUTPUT__EDGE OUTPUT_SKEW; 
input Clk CLOCK; 

} 
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Finally, the command line generates the Vera program template file myfsm.vntmp: 

#define OUTPUT_EDGE PHOLD 
#define OUTPUT_SKEW «1 
# define INPUT_EDGE PS AMPLE 
# include <vera_de fines . vrh> 

program myfsm_test 

// declaring interface, vca signal, and classes.. 

# include *myf sm. if . vrh* 

// define vca_defn, class, instance here if necessary 

{ // Start of myfsn\_test 

} // end of program myfsm_test 

17.1.2 Connecting Vera Testbenches to Verilog Designs 

There are three ways to connect Vera testbenches to Verilog designs: through a test-top file, by driving 
Verilog submodules through direct signal connections, and through the multiple module support dis- 
cussed in Chapter 12. 
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1 7.1 .2.1 Connecting Testbenches Through the Test-top File 

The test-top file method of connecting testbenches to the DUT connects the Vera testbench to the Ver- 
ilog DUT through a test-top. The DUT and the Vera shell file (.vshell) rest on the test-top, and all signal 
connections are made through that test-top. The test-top instantiates the DUT and the Vera shell mod- 
ule. Vera drives the Verilog DUT through the shell module. Finally, the clock generator is on the test- 
top. Figure 17-1 shows the schematic of this configuration. 



Clock Generator 



Device 
Under Test 



Vera Shell File 



4 ♦ 



Vera Testbench 



Interface Specification 



test-top file 



i i 



Figure 17-1 Test-lop method of testbench connection 
Given this setup, the steps to connect a Vera testbench to a Verilog arbiter (rrarb.v) are: 

1. Generate the template files from the Verilog source code using: 
vera -tern -t rrarb -c elk rrarb. v 

This generates the interface file and the test-top file. The interface file specifies the signal 
connections between the DUT and the testbench. If you use the same signal names in the Vera 
testbench as the names in the DUT, you do not need to modify the interface file. 

The clock generator is created in the test-top file. 

2. Compile the Vera testbench source code using: 
_ vera -crop rrarb. vx 

This generates the compiled Vera object files (.vro) and the Vera shell file (.vshell^. 
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3. Run the simulation using: 

vera -nan verilog rrarb. test__top. v rrarb.v rrarb.vshell \ 
+vera_prog=rrarb . vro 

Using this configuration, these steps connect the testbench and PUT without any further work. 

The files for this arbiter are: 

• rrarb.v (the Verilog design) 

• rrarb.vr (the Vera testbench) 

The DUT design generates these files: 

• rrarbJf.vrh (the interface file) 

• rrarb.testjtop.v (the test-top file) 

• rrarb.vshell (the Vera shell file) 

• rrarb.vro (Vera object file) 

rrarb.v 

module rrarb (request, grant, reset, elk) ; 
input [1:0] r eques t ; 
output [1:0] grant ; 
input reset ; 
input elk; 
wire winner; 
reg last_winner; 
reg [1:0] grant; 
wire [1:0] next_grant; 

assign next_grant [0] 

= -reset &( request [0] & 

(-request [1] | la st_w inner) ) ; 

assign next grant 111 

= -reset & ( request [1] & 

(-request [0] | -last_winner) ) ;. .... 

assign winner 

= -reset & -next_grant [0] & 

( last_lvinner | next_grant [ 1 ] ) : ; 

always 8<posedge elk) begin 
las t_w inner = winner ; 

grant = next grant ; - ' 

end 
endmodule 
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rrarb.vr 

#define OUTPUT_EDGE PHOLD 
# define OUTP0T_SKEW #1 
# define INPUT_EDGE PJS AMPLE 
# include <vera_def ines - vrh> 
« include Trarb.if .vrh" 

program rrarb_ test 
{ 

integer i ; 

trace ( ON, PROGRAM, 0 ); 
// reset 

rrarb. request [0] = 1'bO; 

rrarb. request [1] = 1'bO; 

rrarb . reset = 1 ; 

01 rrarb. reset =0; 
// simple requesting 

61 rrarb. request [0] = 1'bl; 

61 rrarb. grant == 2'b01; 

61 rrarb. request [0] = 1'bO; 

rrarb. request [1] = 1'bl; 

€1 rrarb. grant == 2'blO; 

rrarb. request (1] = 1'bO; 
// round-robin test 

61 rrarb. request [0] = 1'bl; 

rrarb. request [1] = 1'bl; 

61 rrarb. grant == 2'b01;// shoud get grant 0, since last was 1 
61 rrarb. grant == 2'blO;// keep asserting both port, should get grant 1 
rrarb. request (03 = 1'bO; 
rrarb. request [11 = 1'bO; 
} // end of program rrarb_test 
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17.1 .2.2 Directly Connecting Testbenches to the DUT 

Direct connections to the DUT eliminate the need for a test-top file. Instead, the testbench is directly 
connected to the DUT through the HDL node method of signal declarations. Using this configuration, 
you must explicitly define how the testbench signals and DUT signals are connected. It is important to 
note that under this configuration, the clock must be defined in the DUT and connected to the testbench 
through a signal declaration. Figure 17-2 shows the schematic for this configuration. 



Device 
Under Test 



Clock Generator 



Vera Testbench 



Figure 17-2 Direct connection between testbench and DUT 

Given this setup, the steps to connect a Vera testbench to a Verilog arbiter (rrarb.v) are: 

1. Compile the Vera testbench source code, including the interface specification, using: 
vera -cmp rrarb . vr 

The interface specification is generally included in the rrarb.if.vrh file and included in the rrarb.vr 
file. This generates the compiled Vera object files (.vro) and the Vera shell file (.vshell). 

2. Run the simulation using: 

vera -run verilog rrarb. v rrarb. vshell +vera_prog= rrarb. vro 
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Using this configuration, the clock must be defined in the DUT and connected to the testbench through 
the interface specification. Further, each signal connection must be done using the hierarchal pathnames 
in the HDL node method. 

The files for this arbiter are: 

• rrarb.v (the Verilog design) 

• rrarb.vr (the Vera testbench) 

• rrarbJf.vrh (the interface file) 

The DUT design generates these files: 

• rrarb.vshell (the Vera shell file) 

• rrarb.vro (Vera object file) 



rrarb.v 

module rrarb; 

parameter Simula tion_cycle = 100 ; 

wire (1:0] request ; 

wire reset ; 

reg elk ; 

wire winner ; 

reg last_winner ; 

reg [1:0] grant ; 

wire [1:0] next_grant ; 

initial 
begin 

elk = 0 ; 

forever begin 

# <simulation_cycle/2) 

elk = -elk ; 

end .**•■" -~ 

end 

assign next_grant [ 0 ] - : 
= -reset &( request[0] & (-requesttl] | last_winner) ) ; 

assign next_grant ( 1 3 

c -reset & ( request [1] fc (-request [0] | -last_winner) ) ? 

assign winner 

= -reset & -next_grant [ 0 ] & ( last_winner | next_grarit [1] ) ; 
always ©(posedge elk) begin 
las t_w inner = winner ; 
grant = next_grant ; 

end 
endmodule 
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rrarb.if.vrh 

#ifndef INC_RRARB_IF__VRH 
# define INC_RRARB_IF__VRH 

interface rrarb 
{ 

output [1:0] request OUT PUT_EDG E OUTPUT_SKEW verilog_node 

• rrarb. request" ; 
input (1:0] grant INPUT_EDGE verilog_node 'rrarb. grant ■ ; 
output reset OUTPUT__EDGE OUTPUT_SKEW verilog_node 'rrarb. reset" ; 
input elk CLOCK verilog_node "rrarb. elk"; 

} 

verilog_node CLOCK "rrarb. elk"; 
#endif 

rrarb.vr 

# define OUTPUT_EDGE PHOLD 
# define OUTPUT_SKEW #1 
# define INPUT_EDGE PS AMPLE 
tinclude <vera — defines ,vrh> 
# include ■ rrarb. if . vrh ■ 

program rrarb_test 
{ 

integer i; 

trace ( ON , PROGRAM , 0 ); 
// reset 

rrarb. request [0] = 1'bO; 

rrarb. request (1] = 1'bO; 

rrarb. reset =1; 

ei rrarb. reset = 0; 
// simple requesting 

61 rrarb. request [0] -= l'bl; 

61 rrarb. grant == 2'b01; 

©1 rrarb. request [0] = 1'bO; 

rrarb. request [1] = l'bl; 

61 rrarb. grant == 2*bl0; 

rrarb. request [1] = 1'bO; 
// round-robin test 

61 rrarb. request [0] = l'bl; 

rrarb. request (13 = l'bl; 

61 rrarb. grant == 2'b01; // should get grant 0, since last was 1 

61 rrarb. grant == 2'bl0;// keep asserting both port, should get grant 1 
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rrarb. request [0) = 1'bO; 
rrarb. request [1] = 1'bO; 
} // end of program rrarb_test 



17.1.3 Multiple Clocking Domains 

There are two ways to run a simulation with multiple clock domains: create multiple clock generators 
in the DUT source files, or create multiple clock generators in the test-top file. 

If you want to use multiple clocking domains with the test_top generators, you should add these lines of 
code after the SystemClock declaration in the test-top file: 

initial begin 

clockname = 0; 
forever begin 
# period/ 2 

clockname = -clockname 

end 

end 

clockname - The clockname is the name of the clock generator. 

period - The period is the period of a single clock cycle, measured in nanoseconds. 

17.2 Creating Testbenches for VHDL Designs 

To integrate Vera testbenches with VHDL designs, you must develop the simulation framework. This 
section includes discussions on each of the files required to integrate Vera testbenches with VHDL de- 
signs and how they are made, instructions on how to connect Vera testbenches to VHDL designs, and 
instructions on how to generate multiple clocking domains. 

17.2.1 . Files for Test-top Connections 

VHDUs version of the test-top connection requires throe key files: design.top % designjop.vha\ 
design Jntf.vhd and vercuinL Each of these files is discussed here. ~ 

17.2.1.1 deslgnAop 

The designtop file is the test top file used to connect the VHDL design to the testbench. To generate 
the top file, use the -vhdl or -vtidl -top compile options: 

vera -cap -vhdl -top fil enam e 

filename - The filename is the name of the Vera testbench source file. This file contains the interface 
specification for the testbench. ... 
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Using the -top switch with the -vhdl switch generates the top file. When the file is generated, you must 
rename it to filenamexop. 

After generating the top file, you must modify it: 

1 . Instantiate the DUT. You must define the DUT component 

2. Create a DUT instance with a valid port map. 

3. Define the signals referenced by the port map. 

4. If the DUT has a system clock, connect the DUTs system clock to the Sys temClbck signal. If the 
DUT does not have a system clock, modify the generated system clock's half period as necessary for 
your simulation. 



Warning - Do NOT modify the vmc_mti entity or architecture. 



The top file is a source file that is modified only if the Vera interface changes (signals are added, delet- 
ed, or renamed) or if the DUT interface changes. If neither changes, the top file does not need to be 
modified or regenerated. 

17.2.1,2 des/gh_top.vhd and design Jntf.vhd 

The design_top.vhd file is generated using the -vhdl switch alone: 
vera -cmp -vhdl filename 

When the -vhdl switch is used alone, the filename Jnxlyhd and /i/ename_top.vhd files are generated. 
These files should not be renamed or modified. If you need to modify the designjLop.vhd file, edit the 
design.top file. These files must be compiled with the VHDL source files. The -vhdl switch checks for 
the existence of & filename. top file. If the file does not exist, a warning is issued and the 
filenamejiop.vhd file is not generated. 

VHDL tasks to be called from Vera should be encapsulated and included in the^fcname_top.vhd file. 

Vera's global variables are copied into the filename jbop.\hd file so that they can be viewed and de- 
bugged. They are prepended by var_. Only Vera variables of type integer, bit, and bit[] are copied. 

Inside the^ifcnamOop.vhd file is a reference to the Vera shared library vera_mtLdlL For VSIM to find 
this file, you must set LDJJBRARYJ>ATH to $VERA_HOAtE/lib. 



17.2.1.3 vera.ini 

The initialization file vera.ini is required for the VSIM command. Vera first checks the current working 
r directory and then the SVERAJiOME directory. This file must be present for Vera to run. 

The vera.ini file contains lines of this syntax: 1 ' ' ~" ■ 
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n am e_ token value_token 

nomejoken - The valid namejokens arc: 

vcrajoad 

vera_mload 

vera_mload_define 

vera_stop_on_error 

vera_continue_on_error 

vera_exit_on_ern>r 

vera_finish_on_end 

vera_debug_on_error 

vera_tcxt_debug 

vera_semaphore_size 

vera_region_size 

vera_mailbox_size 

vera_random_seed 

vera_rand48_seed 

map 

value Joken - The value joken varies depending on the name joken. The valid tokens arc listed in the 
subsequent definitions of the namejokens. 

verajoad 

The verajoad token specifies an HDL object (.vro) file to be used with the simulation. The syntax is: 
vera_lo*d filename 

filename - The filename is the .vro object file to be used. Multiple files can be specified by separating 
them with commas. 

vera.mioad 

The vera.mload token specifies a .vrl file that lists multiple object files to be used with the simulation. 
The syntax is: 

v«r*_mload filename 

filename - The filename is the .vii file that lists the object files to be used. Multiple files can be 
specified by separating them with commas. 

vera_mload_define 

The vera_mload_define specifies a text macro. The syntax is 

v*ra_mload_d«£lne macro_name=val ue 
macro jname - The macro_name is the string of text to be substituted for. 
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value - The text macro is optionally set to value. 

Text macros defined at compile time are particularly useful when using the conditional compilation di- 
rectives. 

vera_stop_on_error 

The vera__stop_on_error token causes the simulation to stop immediately when a simulation error is 
encountered. The syntax is: 

vera_etop_on_error switch 
switch - The switch is used to turn the mode on. A value of l f "true," "on," or "yes" turns the mode on. 
The default setting is to execute the remaining code within the present simulation time. 

* 

vera_continue_on_error 

The vera_continue_on_ent>r causes the simulation to continue after, a verification error is encoun- 
tered. The syntax is: 

▼era_continue_on_error switch 
switch - The switch is used to turn the mode on. A value of 1, "truer "on" or "yes** turns the mode on. 

This token causes the simulation to continue when verification errors (such as failed expects) occur. 
This token overrides the vera_ejdt_on_error token. 

vera_exit_on_error 

The vera_exit_on_emor token causes the simulation to be terminated when a simulation error is en^ 
countered. The syntax is: 

vera_ejcit_on_error swi tch 

switch - The switch is used to turn the mode on. A value of 1, "true," "on " or "yes" turns the mode on. 

The default setting is to stop the simulation and return to the HDL shell. : . i 

vera_finish_on_end 

The vera_Cnish_on.end token specifies that the simulation is finished when a simulation ran is com- 
pleted. The syntax is: 

v*r*_f ini«h__oo_end swi tch 

switch - The switch is used to turn the mode on. A value of 1, "true " "on " or "yes" turns the mode on. 

The default setting is to stop the simulation and return to the HDL shell. 
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vera_debug_on_error 

The vera_debug_on_error token invokes a debugger when a verification error (such as a failed expect) 
is encountered. The syntax is: 

vera_debug_on_error switch 

switch • The switch is used to turn the mode on. A value of 1, "truer "on," or "yes" turns the mode on. 

The vera_debug_on_error token determines the debugger used when a verification error is encoun- 
tered. If the HDL simulator has control when the error occurs, the simulator's debugger is invoked. If 
Vera has control when the error occurs, Venfs debugger is invoked. - . 

If the vera_debug_on_error token is not used, the behavior depends on the particular HDL simulator. 
vera_text_debug 

The vera_text_debug token launches the text debugger when an error occurs. The syntax is: 

vera_text_debug switch 
switch - The switch is used to turn the mode on. A value of 1, "true" "on" or "yes" turns the mode on. 

vera_semaphore_size 

The vera_semaphore_size token specifies the maximum number of semaphores within the simulation. 
The syntax is: 

vwra_Bemaphore_ «ire size 
size - The size specifies the maximum number of semaphores within the simulation. 
The default limit is 2048. 

vera_region_stze 

Tne vera_region_size token specifies the maximum number of regions within the simulation. The syn- 
tax is: 

v« r a_reglon_« ire size 
size - The size specifies the maximum number of regions within the simulation.. 
The default limit is 256. 

vera.mailbox.size 

The vera_mailbox_sire token specifies the maximum number of mailboxes within the simulation. The 
syntax is: 

v*ra_mailbox«s_air« size 
size - The size specifies die maximum number of mailboxes within the simulation- 
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The default limit is 256. 
vera_random_seed 

The vera_random_seed token sets the seed for calls to the randomO system function. The syntax is: 

vera_random_fleed seed 
seed - The seed can be any valid expression evaluating to a number. 

vera_rand48_seed 

The vera_random_seed token sets the seed for calls to the rand480 system function. The syntax is: 
vora_rand4 8_«eed seed 

seed - The seed can be any valid expression evaluating to a number, 
map 

The map token maps Vera enumerated types to VHDL enumerated types. The syntax is: 
nap vera_enum_name num vhdl_enuml vhdl_envm2 . . . vhdl^enumN 

vera_enumjname - The vera_enum_name is the Vera enumerated type category. " - ? 1 ; 

num - The num specifies how many elements there are in the category. 

vhdljenumN - The vhdl_enumN is the VHDL enumerated type to which the Vera type is mapped. 

When the map token is executed, each Vera enumerated type (up the specified number) is sequentially 
mapped to the specified VHDL name. 

For example, in Vera, an enumerated type is defined as: 

enum vera_color = VERA_RED, VERA_YELLOW , VERA_GREEN , VERA_BLUE; 

In VHDL, an enumerated type is defined as: 

type VhdlColor is {VHDL_R£D, VHDL_YELLOW, VHDL_GR£EN, VHDL.BLUE) ; 

To equate the two, use the map command: 

map vera_color 4 VHDL_RED VHDL_YELLOW VHDL_GREEN VHDL_BLUE 

17.2.1.4 vera 

The vera command is also supported by VSIM: 

vera token^name tokeo_value 
These token and value combinations are allowed: 
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debug 

load filename 
mload filename 

debug 

The debug token launches the Vera debugger when invoked. The syntax is: 
vera debug switch 

switch - The switch is used to turn the mode on. A value of l f "true " "on" or "yes" turns the mode on. 
load 

The load token specifies an HDL object (.vro) file to be used with the simulation. The syntax is: 
vera load filename 

filename - The filename is the .vro object file to be used. Multiple files can be specified by separating 
them with commas. 

mload 

The mload token specifies a .vrl file that lists multiple object files to be used with the simulation. The 
syntax is: 

vera mload filename 

filename - The filename is the .vrl file that lists the object files to be used. Multiple files can be 
specified by separating them with commas. 

17.2.1.5 VSlMCommandsinvera.ini 

Vera supports the VSIM Restart command. However, the Save and Restore commands arc not support- 
ed. 

17.2.2 Connecting Vera Testbenches to VHDL Designs r w rn .> 

You can connect Vera testbenches to VHDL designs using two methods: connecting the testbench 
through a test-top configuration, or directly connecting the testbench to nodes within the design. 




Synopsys lnc/ ,: 



326 Chapter 1 7. Testbench Setup and Usage Notes 



Vera 4.0 User's Manual 



1 7.2.2.1 Connecting Testbenches Through the Test-top 

The test-top method of connecting a Vera testbench to a VHDL design connects the testbench through 
the test-top file (designjtop.vhd). The test- top file is generated from the desigtutop file. The DUT is 
connected directly to the Vera testbench through the Vera interface and through the VHDL interface. 
Figure 17-3 shows the schematic for this configuration. 



Clock Generator 



Device 
Under Test 



Vera Interface 



VHDL intf.vhd File 



Vera Testbench 



test-top file 



Figure J 7-3 Test-top method of testbench connection 
Under this configuration, the clock generator is in the test-top {desigrijtop.vhd) file. 
Given this setup, the steps to connect a Vera testbench to a VHDL arbiter (rrarb.vhd) are: 

1. Generate the rrar&ro/? file from the Vera source code using: ; - i,. ", '2 \ ■ ' \ ' 
vera -cmp -vhdl -top rrarb.vr - 

This generates the rrarbjop file. 

2. Edit the rrarb.top file to include the definition and instantiation of the DUT. 

3. Generate the VHDL interface file (rrarbjntf.vhd), test-top file (rrarbjtop.vhd), and compiled Vera 
object file (rrarb.vro) using: 

vera -cmp -vhdl rrarb.vr 
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This generates the interface file, test-top file, and compiled Vera object file from the Vera source 
code and the previously generated rrarLtop file. These files should not be edited. If you edit the 
rrarb Jiop.vhd file and recompile the Vera source code with the -vhdl switch, you lose the edits you 
made. 

4. Run the simulation with the VHDL interface file (rrarb Jntf.vhd), the test-top file {rrarbjtop.vhd), the 
Vera object file (rrarb.vro) and the VHDL DUT (rrarb.vhd). 

The files from this arbiter are: 

• rrarb.vhd (the VHDL design) 

• rrarb.if.vr (the Vera interface file) 

• rrarb.vr (the Vera testbench) 

When compiled, these files are generated: 

• rrarb Jntf.vhd (the VHDL interface file) 

• rrarb Jop.vhd (the test-top file) 

• rrarb.vro (Vera object file) 

rrarb.vhd 

library IEEE; 

use IEEE. std_logic_1164 .all; 
use IEEE." std_logic_arith. all; 
use IEEE. std_logic_unsigned. all; 

entity rrarb is 
port ( 

request : in std_logic_vector ( 1 downto 0); 
grant : out std_logic_vector (1 downto 0); 
reset : in std_logic; 
elk : in std_logic 

); 

end entity rrarb; 

architecture rrarb_arch of rrarb is 
signal winner : st<3Llogic : = ' 0 ' ; 
signal last_winner : std_logic : = ' 0 ' ; 

signal next_grant : std_logic_vector (1 downto 0) := •00'; 
begin 

next_grant (0) <= (not reset) and ( request (0) and 

{(not request (1)) or last_winner) ) ; 
next_grant(l) <= (not reset) and ( request (1) and 

((not request(O)) or (not last_winnef) ) ) ; 
winner <= (not reset) and (not next_grant ( 0 ) ) and 
(last_winner or next_grant (1) ) ; 
process (elk) is 
begin 
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if (clk'event and elk = '1') then 
last_winner <= winner; 
grant <= next_grant; 
end if; - 
end process; 
end rrarb_arch; 

rrarb.if.vrh 

#ifndef INC_RRARB„IF_VRH 
#define INC_RRARB_IF_VRH 

interface rrarb 
{ 

output [1:0] request OUTPUT_EDGE OUTPUT_SKEW; 

input [1:0] grant INPUT_EDGE ; 

output reset OUTPUT_EDGE OUTPUT__SKEW; 

input elk CLOCK; 
} // end of interface rrarb 
tendif 

rrarb.vr 

♦define OUTPUT_EDGE PHOLD 
# define OUTPUT_SKEW #1 
# define INPUT_EDGE PS AMPLE 
# include <vera_def ines . vrh> 
# include • rrarb. if .vrh" 

program rrarb_test 
{ 

integer i ; 

trace ( ON , PROGRAM ,0 ) ; 
// reset 

rrarb. reques t(0] = 1'bO; 

rrarb. request [1] = 1'bO; 

rrarb. reset =1; 

6 1 rrarb . r e s e t = 0 ; 
/ / s imp le r eques t ing . 

61 rrarb. request (0] = l'bl; 

61 rrarb. grant == 2'b01; 

61 rrarb. request [0] = 1'bO; 

rrarb. reques t[l] = l'bl; 

61 rrarb. grant == 2'blO; 

rrarb. reques t(l] = 1'bO; 
// round-robin test ' 
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61 rrarb. request [0] = l'bl; 
rrarb. request 11] = l'bl; 

ei rrarb. grant == 2'b01; // shoud get grant 0, since last was 1 
61 rrarb. grant == 2'bl0;//keep asserting both port, should get grant 1 
rrarb. request [0) = 1'bO; 
rrarb. request [1] = 1'bO; 
} // end of program rrarb_test 

rrarb.top (after being modified) 

library IEEE; 

use IEEE . st<3L_logic_1164 . all ; 

entity rrarb_bench is 
end; 

architecture rrarb_bench_arch of rrarb_bench is 
# include rrarb. inc_vhd SIGNALS 
component rrarb 
port ( 

request : in std_logic_vector (1 downto 0); 
grant : out s td_logic_vec t or (1 downto 0) ; 
reset : in std_logic; 
elk : in stcLlogic 

) ; 

end component; 
component vmc_mti 
end component ; 
begin 

system_clock <= not system_clock after 50 ns; 
rrarb_clk <= systeny_clock; 
rrarb_inst: component rrarb 
port map ( 

request => rrarb_request # ... 

grant =>. rrarb_grant, 

reset => rrarb_reset, 

elk => rrarb_clk 

); 

vmc_mti_inst : vmc_mti ; 
♦include rrarb . inc_vhd TASKS 
end; 
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17.2.3 Directly Connecting Testbenches to the DUT 

For VHDL, the model for directly connecting testbenches to the DUT is identical to using the test-top 
method, except for how the signals are connected. To directly connect the testbench to the DUT, you 
must use the HDL node method when specifying the interface signals. 

The same arbiter from the previous section is included here with the connection made through direct 
nodes. Note the rrarb.if.vr file in particular. 

rrarb.vhd 

library IEEE; 

use IEEE. std_logi c_l 164 .all; 
use IEEE. std_logic_arith. all; 
use IEEE. std_logic_unsi gned. all; 

entity rrarb is 
end entity rrarb; 

architecture rrarb_arch of rrarb is 
signal winner- : std_logic := '0'; 
signal last_winner : std_logic := '0'; 
signal reset : std_logic := '0'; 
signal elk : std_logic := '0'; 

signal next__grant : std_logic_vector (1 downto 0) := - 00'; 
signal grant : std_logic_ vector (1 downto 0) := '00"; 
signal request : std_logic_vector (1 downto 0) := •00"; 
begin 

elk <= not elk after 50 ns; 
next_grant (0) <= (not reset) and ( request (0) and 

((not request (1)) or last_winner) ) ; 
next_grant (1) <= (not reset) and ( request (1) and 

((not request (0)) or (not last_winner) ) ) ; 
winner <= (not reset) and (not next_grant ( 0 ) ) and 

(last_winner or next_grant ( 1 ) ) ; 
process (elk) is 
begin 

if (elk 'event and elk = '1 # ) then 
las t_w inner <= winner; 
grant <= next_grant; 
end if 
end process; 
end rrarb_arch; 
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rrarb.if.vrh 

iifndef I NC_RRARB_ I F_VRH 
# define INC_RRARB_IF_VRH 

interface rrarb 
{ 

output [1:0] request OUTPUT_EDGE OUTPUT_SKEW vhdl.node 

• / r r arb_bench / r r arb_ins t / r eques t • ; 
input [1:0] grant INPUT_EDGE vhdl_node 

• / rrarb Jbench/rrarb_inst /grant ' ; 
output reset OUTPUT_EDGE OUTPUT_SKEW vhdl_node 

• /rrarb_bench/rrarb_inst /reset • ; 
input elk CLOCK vhdl_node ■ /rrarb_bench/rrarb_inst/clk- ; 
} // end of interface rrarb 

vhdl_node CLOCK • /rrarb_bench/rrarb_inst/clk" ; 
#endif 

rrarb-vr 

#define OUT PUT_EDGE PHOLD 
#define OUTPUT_SKEW #1 
tdefine INPUT_EDGE PSAMPLE 
# include <vera_def ines - vrh> 
# include "rrarb.if.vrh* 

program rrarb_test 
{ 

integer i; 

trace ( ON , PROGRAM ,0 ) ; 
// reset 

rrarb. request (03 = 1'bO; 

rrarb. request [1] = 1'bO; 

rrarb. reset =1; 

@1 rrarb. reset =0; 
// simple requesting 

61 rrarb. request [0] = l'bl; 

@1 rrarb. grant == 2'b01; 

ei rrarb. request [0] = 1'bO; 

rrarb. request (1] = l'bl; 

ei rrarb. grant == 2'bl0; 

rrarb. request [1] = 1'bO; 
// round- robin test 

ei rrarb. request (0] = l'bl; 

rrarb. request [1] = l'bl; 

©1 rrarb. grant == 2'b01; // shoud get grant 0, since last-was 1 
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61 rrarb. grant == 2'bl0;//keep asserting both port, should get grant 1 
rrarb. request [0] = 1'bO; 
rrarb. request (1] = 1'bO; 
} // end of program rrarb_test 

rrarb.top (after being modified) 

library IEEE; 

use IEEE. std_logic_1164 . all; 

entity rrarb_bench is 
end; 

architecture rrarb_bench_arch of rrarb_bench is 
# include rrarb . inc_vhd SIGNALS 
component rrarb 
end components- 
component vmc_mt i 
end component; 
begin 

system_clock <= not system_clock after 50 ns; 

rrarb_clk <= system_clock; 
rrarb_inst: rrarb; 
vmc_mt i_ins t : vmc_m t i ; 
# include rrarb . inc_vhd TASKS 
end; 



17.2.4 Multiple Clocking Domains 

To run simulations with multiple clocking domains, you must; 

1 . Define an interface for each clocking domain you want to have in the interface file. 

2. Modify the filename juap.vhA file to instantiate the clock; 
— signal signal_name : «td_logic : = % 0 % ; 

3. Modify the filename _top.vhd file to connect the clock and set the half period: 
clock^name <= not cloc7c_name after period ns; 



Note - You should have a clock for each interface. 
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17.3 VHDL Testbench Usage Notes 

This section includes several usage notes on using VHDL testbenches. 

17.3.1 Valid VHDL Signal Types 

Vera supports the assertion and querying of only these VHDL signal types: 

integer 
bit 

bit_vector 
stdjogic 
std_logic_vector 
std_ulogic 
std_ulogic_vecto r 
boolean 
boolean array 
enumerated types 



17.3.2 VHDL Plus Arguments 

In the vera.ini file, you can specify plus arguments. The syntax is: 
argument value 

argument - The argument is the name of the plus argument being defined. 

value • The value is the value of the plus argument There must be a space between the argument and 
the value. 

For example, the VHDL equivalent to the Verilog plus argument +vera_my_arg=100 is: 

vera_my_arg= 100 
Note the space between the argument name and. the argument value. 

17.3.3 Features Not Yet Supported for VHDL 

These features are not yet supported for VHDL testbenches: 

• Multiple module support 

• Vera-CORE 

• Calling Vera tasks from VHDL 




Synopsya Inc. 



334 Chapter 1 7. Testbench Setup and Usage Notes 



Vera 4.0 User's Manual 



U 

N 

m 
O 

O 

m 

hi 
o 

M 

m 
a 



Synppsys |nc. £ 



Vera 4.0 User's Manual 



Chapter 1 8. Compilation 335 



18. Compilation 



The Vera compiler accepts a Vera source program and generates binary Vera objects. This chapter dis- 
cusses the Vera compiler, preprocessor, and runtime control. It details Vera's use with different HDL 
simulators, with C functional simulators, and as a stand-alone cycle-based simulator. This chapter in- 
cludes these sections: 

• Compiler Overview 

• Preprocessor 

• General Options 

• Compile Options 

• Running Vera with HDLs 

• Modular Compilation 

• Dynamic Loading of Vera Object Modules 

• Running Vera Stand-alone 

18.1 Compiler Overview 

The compiler options are listed with a brief description in Table 18-1. 

Table 18-1 Vera Compiler Options and Definitions 

Option Definition 

-help Lists valid compiler options 

-cap Compiles Vera source files 

-alim Sets maximum number of elements 

in arrays 

-ami Invokes ansi preprocessor 

-g Invokes compiler using debug 

information 

-h Updates -vrh file 

-hnu Updates .vrh file only .if it has 

changed 

-i Produces ASCII interface 

definition 

-ip Compiles an IP core 

-max_orror Sets the maximum number of errors 
before compilation failure 



-q 1 Compiles' Ln Quiet mode ' 
■ r " 
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Table 18-1 Vera Compiler Options and Definitions (Continued) 



Option 




Definition 




- times cale 


Sets times cale 




-top 


Creates VHDL top file 




-vndl 


Processes VHDL top file 


-D 




Specifies text macro 


-I - 




Includes directory in search Dath 


-PP 




Invokes preprocessor. 


-proj 




Creates Vera shell files from 
project file 


-run 




Runs simulation 


-tern 




Invokes Vera template generator 




-c 


Specifies clock signal 




-d 


Specifies dump file 




-nav 


Uses Magellan for simulation 
control 




-t 


Specifies Verilog module name 


-v 




Returns the compiler version 
number . - : 


-vcon 




Generates a . vcon file 



The options available for use with Vera-CS are listed with a brief description in Table 18-2. 
Table 18-2 Vera-CS Options and Definitions 



Option Definition 



. -e 


Exits simulation on error 


-f 


Includes .vrl file in the compile 


-i 


Specifies initialization file 


-« 


Pauses simulation on error 


-t 


Invokes text-based debugger 



18.2 Preprocessor 

Vera programs are processed by a custom preprocessor prior to being translated by the compiler. The 
preprocessor handles file inclusion, text macros, and conditional compilation. 

18.2.1 File Inclusion 

A Vera source fik ; can include another Vera source file by reference using the include construct The 
" syntax is: ' CJ.^ii'..rj . — _ # ^ *j£* ' 
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#includo ~path_to_£ile m 

path Jo JUe - The pathjojile can be the absolute or relative pathname to the include file. If the file is 
is in $VERA_HOME/lib, the quotes can be replaced by angled brackets (o), and only the file name 
is required. 

The <verajiefines.vrh> file should always be included. 

When the Vera compiler encounters an include statement, it replaces the include line with the entire 
file. 

Note - You cannot have spaces before the # in include statements. 



18.2.2 Text Macros 

Vera also supports text macros. The syntax to define a text macro is: 

# define macro__name macro_value; 

macrojname - The macro _name is the name of the constant as it will be referenced throughout the Vera 
program. 

macro _\alue - The macro _value is the value assigned to the macrojname. It must be a constant 
numeric or word substitution. 

Note - You cannot have spaces before the # in text macros. 

This is an example of text macros: 

# define worcLwidth 32 

tdefine ODTPUT_EDGE PHOLD 

#define OUTPUT_SKEW #1 

♦define INPUT_EDGE PSAMPLE 

18.2.3 Conditional Compilation 

The Vera preprocessor supports conditional compilation using #ifdef and #ifndef directives. The syntax 

is: 

iifdef macro_name 
#ifndef macrojname .... 

macrojname - The macro_name is the name of the text macro that determines the conditional. 

Note - You cannot have spaces before the # in conditional directives. 
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The ifdef directive conditionally compiles the text after the directive if the specified text macro has 
been defined. 

The ifndef directive conditionally compiles the text after the directive if the specified text macro has 
not been defined. 

Each of these directives can be used with the #else directive. The syntax is: 
ielee 

The else directive conditionally compiles the text after the directive if the previous ifdef or ifndef 
failed. ' 

Conditional compilation should be terminated using the #endif directive. The syntax is: 
iendif 

This is an example of a conditional compilation directive block: 

#ifdef HACROl 

// This code is for MACROl 

#else 

// This code is not for MACROl 
#endif 



tifndef MACROl 

// This code is not for BOO 

#endif 

18.3 General Options 

When the Vera compiler is invoked, several options can be called. The syntax to invoke the compiler is: 
vera general_options input_ filename 

general Options - Hie general options used with the Vera compiler and their definitions are listed in Ta- 
ble 18-3. 

Table 18-3 General Options 
Option Definition 



Compiles Vera source code 
-I . . Includes directory in search path 

-pp Invokes preprocessor - 

-proj Creates Vera shell files from project file 
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Table J 8-3 General Options (Continued) 



Option 


Definition 


-run 


Runs simulation 


-tern 


Invokes Vera template generator 


-v 


Returns the compiler version number 


-vcon 


Generates a .vcon file 



input Jilename - The input Jilename is the name of the Vera source file being processed, 
-crnp 

The -cmp option compiles Vera source code. It is discussed in detail in Section 18.4. 
-I 

The -I option adds a specified path to the search path for include files. The syntax is: 
-I pathname 

poth_name - The pathjname is the absolute or relative path to the directory you want to add to your 
search path. 

The -I option adds the specified path to all include files. If this option is invoked, be sure to declare all 
include files with respect to the specified path. 

-PP 

The -pp option invokes the Vera preprocessor. The syntax is: 
-PP 

When the -pp option is used, the preprocessor is explicitly used on the input file. When using the -cmp 
option, the preprocessor is automatically invoked. 

-pro] 

The -proj option is used when creating and using IP cores. The syntax is: 
-proj 

For more information on Vera-Core, see Chapter 13., **Vera-CORE. M 
-run 

The -run option is used to run a Vera simulation with an HDL design. The syntax is: 
-run 

For more information on running simulations, see Section 18.5, Running Vera with HDLs.** 

-r 
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-tern 

The -tem opiion invokes the Vera template generator. The syntax is: 
-tern 

The Vera template generator is discussed in more detail in Section 17.1.1, "Vera Template Generator." 
-v 

The -v* option returns the version number of the Vera compiler. The syntax is: 



-vcon 

The -vcon option generates a .vcon file for use with multiple module support The syntax is: 
—vcon 

For more information on multiple module support, see Chapter 12., "Multiple Module Support." 

18.4 Compile Options 

The Vera compiler is primarily used to compile Vera source code using the -cmp option. The syntax is: 

vera -cusp compiler_options inputs filename output_ filename 
compiler _options - The compiler options and definitions are listed in Table 18-4. 

Table 18-4 Vera Compiler Options 

Option • Defini tion 

-alim Sets the maximum number of array 

elements 

-ami Invokes the ansi preprocessor 

-D. Specifies a macro name 

-a 

-h Updates the .vrh file 

-hnu Updates the .vrh file only if it 

has changed 

-i Produces an ASCII interface 

definition . ; . f . 

-ip Generates an IP core 



-max_ error Sets the maximum number of errors 

c before compilation fa ilure 

.-."» • ■ _ •. „ . 
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Table 1 8-4 Vera Compiler Options (Continued) 

Option D efinition 

Compiles in quiet mode, without a 
header 

Specifies a timescale 
Generates a VHDL test_top file 
Generates VHDL template files 

input Jdename - The input Jilename is the name of the Vera source file being compiled. 
output Jilename - The outputJUename is the prefix of the output file. 

When the -cmp option is invoked, the compiler generates the object file outputJUenamcvro and the 
shell file output Jilename.vshelL If the output file is not specified, the prefix of the input file is used. 
Compiler options are used on top of this basic function. 

-alim 

The -alim option explicitly sets the maximum number of elements allowed in arrays. The default limit 
is 1024. The syntax is: 

-alim number 

number - The maximum number of elements in an array is specified by <number>. 
-ansi 

The -ansi option preprocesses the Vera source code in ANSI mode. The syntax is: 
-an«i 

-D 

The -D option specifies a text macro. The syntax is: 

-D macro_name=value 
macro _namt - The macrojname is the string of text to be substituted for. 
value - The text macro is optionally set to value. 

Text macros defined at compile time are particularly useful when using the conditional compilation di 
rectives. 

-9 

The -g option generates debugging information. The syntax is: 
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-h 

The -h option updates the .vrh header file. The syntax is: 

The -h option automatically generates include files with global declarations from the Vera source code, 
-hnu 

The -hnu option updates the .vrh header file only if it has changed. The syntax is: 
-hnu 

The -hnu option functions like the -h option except that it only updates the .vrh file if there are changes 
to it 

-i 

The -i option generates an ASCII file containing the interface definition. The syntax is: 

The -i option generates a .vri interface file from the Vera source code. This is interface specification 
produces the corresponding generated interface file: 

input data-in [31:0] PSAMPLE 1 

output ack[31:0] PHOLD 0 

inout data_out [1:0] PSAMPLE 0 PHOLD 1 

input if_0 data_in 32 PSAMPLE 1 

output if_0 ack 32 PHOLD 0 

inout if_0 data_out 1 PSAMPLE 0 PHOLD 1 

-ip 

The -ip generates Vera object files that can be used as IP cores. The syntax is: 

When the -ip option is used, the Vera object files can be used without a runtime license. How IP cores 
arc used and generated is discussed in detail in Chapter 13., "Vera-CORE." 

-max_error 

The -max_error option specifies how many errors are encountered before the compile fails. The syntax 
is: 

-inax_error number 

number - The number specifies the maximum number of errors the compiler can encounter before the 
compilation fails. 
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The -q option compiles the code in quiet mode. The syntax is: 

When the compiler is run in quiet mode, the header information is shortened and limited to only com- 
pile information. 

-timescale 

The -timescale option explicitly defines the simulation timescale inside the Vera shell file. The syntax 
is: 

-timeacale= scale 
scale - The scale specifies the cycle length in nanoseconds. 
The -timescale option generates this statement at the top of the Vera shell file: 

* timescale scale 

-top 

The -top switch is used to generate a test_top file for VHDL designs. The syntax is: 
-top 

-vhdl 

The -vhdl switch is used to generate template files for VHDL designs. The syntax is: 
-vhdl 

18.5 Running Vera with HDLs 

Vera can be run with HDL designs using the -run option with plus arguments. The syntax is: 

vara -run filename &rgs - r ~, .. 
filename - The filename is the executable HDL file compiled with the Vera libraries. 
orgs - The plus arguments and their definitions are listed in Table 18-5. 

Table 18-5 Plus Arguments - - . 



Plus Argument 


Definition 




♦vera_ load 


Specifies 


a single object file 


+vera_jaload 


Specifies 


a file with a list 




of object 


files 


+ vera_s top_on_error 


Execution 


stops on simulation 




error 
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Table 18-5 Plus Arguments (Continued) 

Plus Argument Definition 

+vera_continue_on_error Execution continues after 

verification error 

+vera_exit_on_error Exits simulator on error 

+vera_f inish_on_end Exits simulator when 

simulation finishes 

+vera_debug_on_error Invokes Vera debugger on error 

+vera_text_debug Launches the Vera text 

debugger on error 

+vera_semaphore_size Specifies maximum number of 

semaphores 

+vera_region_size Specifies maximum number of 

regions 

+vera_mailbox_size Specifies maximum number of 

mailboxes 

+vera_load 

The +vera_load argument specifies an HDL object (.vro) file to be used with the simulation. The syn- 
tax is: 

♦ vera_load= fi lename 

filename - The filename is the .vro object file to be used. Multiple files can be specified by separating 
them with commas. 

+vera_mload 

The +vera_m!oad argument specifies a .vrl file that lists multiple object files to be used with the simu- 
lation. The syntax is: ^ 

♦vera_mload= filename ( • 

filename - The filename is the .vrl file that lists the object files to be used. Multiple files can be 
specified by separating them with commas. 

+vera_stop_on_error 

The +vera_stop_on_error argument causes the simulation to stop immediately when a simulation error 
is encountered. The syntax is: 

♦v«ra_«top_oa_error 

The default setting is to execute the remaining code within the present simulation time. 
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+vera_continue_on_error 

The +vera_continue_on_error causes the simulation to continue after a verification error is encoun- 
tered. The syntax is: 

+ve ra_c out lnue_on_©rxo r 

This argument causes the simulation to continue when verification errors (such as failed expects) occur. 
This argument overrides the +vera_exit_on_ern)r argument 

+vera_exK_on_error 

The +vera exk_on_error argument causes the simulation to be terminated when a simulation error is 
encountered. The syntax is: 

■fvera_exit_on_error 
The default setting is to stop the simulation and return to the HDL shell. 

+vera_finish_on_end 

The +vera_finish_on_end argument specifies that the simulation is finished when a simulation run is 
completed. The syntax is: 

♦ ver a_f ixxi sb_on_end 
The default setting is to stop the simulation and return to the HDL shell. 

+vera_debug_on_error 

The +vera_debug_on_error argument invokes a debugger when a verification error (such as a failed 
expect) is encountered. The syntax is: 

♦vera_debug_on_error - , 

The +vera_debug_on_error argument determines the debugger used when a verification error is en- 
countered. If the HDL simulator has control when the error occurs, the simulator's debugger is invoked. 
If Vera has control when the error occurs, Vera's debugger is invoked. * : ' 

If the +vera_debug_on_ern>r argument is not used, the behavior depends on the particular HDL simu- 
lator. * 

For example, with Verilog-XL, if the simulator has control, an interactive prompt is invoked. If Vera 
has control, the simulator invokes the interactive prompt when control passes back to the simulator. 

With VCS, regardless of where control is, the interactive prompt is invoked. 
+vera_text_debug 

The +vera_tert_debug argument is used to launch the Vera text-based debugger when an error is en- 
countered. The syntax is: 

♦▼era_debug_wiadow 

* * 

Synopsyslnc. 
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+vera_semaphore_size 

The +vera_semaphore_size argument specifies the maximum number of semaphores within the simu- 
lation. The syntax is: 

+vera_semaphore_s±ze_size 
size - The size specifies the maximum number of semaphores within the simulation. 
The default limit is 2048. 

+vera_region_size 

The +vera_region_size argument specifies the maximum number of regions within the simulation. The 
syntax is: 

+vera_region_flise_size 
size - The size specifies the maximum number of regions within the simulation. 
The default limit is 256. 

+vera_mailbox_stze 

The +vera_mailbox_size argument specifies the maximum number of mailboxes within the simulation. 
The syntax is: 

+vera_mailboxee_eize_size 
size - The size specifies the maximum number of mailboxes within the simulation. 
The default limit is 256. 

18.6 Modular Compilation 

Vera programs can be compiled modularly at the program, task, and function levels! This allows you to 
make changes to individual files and reload the changes. There is no need to recompile or reload the 
HDL design code when compiling modularly. 

Modular compilation requires these conditions: 

• Variables declared in the top block must be declared external if tasks and functions 
compiled separately reference them. 

• Interface specifications in subroutine modules must match exactly those declared in 
the main program file. 

• Naming conflicts with subroutines can be resolved using local subroutine names. 

This is an example of two separate files linked at simulation time using modular compilation: 
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tst_chip.vr 

program test_my„chip 
interface my_chip_prts { 

input reqO PSAMPLE vca rO; 

output ackO NDRTVE; 

inout[7:0] dadaO PSAMPLE NDRIVE; 

input reql PSAMPLE vca rO; 

output ackl NDRIVE; 

inout[7:0] datal PSAMPLE NDRIVE; 

) 

port dt_prt { 
req; 
ack; 
data; 

} 

bind dt_prt . portO { 

req my_chip_prts - reqO ; 
ack my_chip_prts . ackO ; 
data my_chip_prts .dataO ; 

) 

bind dt_prt portl { 

req my_chip_prts . reql ; 
ack xny_chip_prts.ackl; 
data my_chip_prts . datal ; 

} 



integer i, 3; 
bit dir; 

bit [7:0] my_data; " 1 

♦extern task handshake with dt_prt ( 
bit direction, bit [7:0] h_data 

); 

vca < ON , my_chip_prt s ) ; 
for(i =0; i < 10; i++) { 

xny_data = random ( ) ; 

dir = i; 

handshake with port0(dir, my_data) ; 
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hs_tasks.vr 

port dt_prt { 
req; 
ack; 
data; 



extern integer i ( j; 

local task what_is_ij () { 

printfCtop block i = %d j = %d\n", i, j); 

) 

task handshake with dt_prt (bit direction, bit [7:0] h_data) { 
©0,1000 $req == l'bl; 
$ack = l'bl; 
61 $ack <= 1'bO; 
if (direction) $data = h_data; 
else $data == h_data; 
what_is_i j ( ) ; 



These two files can be compiled separately to generate the object files, tstjchip.vw, and hsjiasks.vro. A 
Vera list (.vrl) file lists the object files to be linked at simulation time. 

tst_chip.vrl 

tst_chip.vro 
hs_ tas ks . vro 

At simulation time, the argument +vera_mload = tst_chp. vrl must be called. 



1 8.7 Dynamic Loading of Vera Object Modules 



Vera testbenches can be loaded dynamically, without recompiling or reloading the HDL design. This al- 
lows for rapid development and easy assembly of regression tests. To enable dynamic loading, Vera 
provides these user-defined HDL tasks: 

$ vera.load ( * fx 1 ename . vro * ) ; 
$v«ra_xalo*d ( * fx 1 ename . vrl * ) ; 

filename - The filename should be an object file when using $vera_load or a Vera list file when using 
$vera_mload. 

These tasks can be invoked from an interactive prompt or executed from a command file. However, 
they should not be invoked from within the HDL circuit description files. 



> 



} 
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Most often, you want to reset the simulation before loading a separate testbench. To reset a simulation, 
use the $reset command: 

preset 

An entire regression can be run by adding the appropriate sequence of resets, loads, and mloads to a 
command file and executing it 

For example, assume this plus argument is used to launch a simulation: 

+vera_load=routerl . vro 

Using this plus argument, Vera loads routerLvro and runs the testbench routerl. When the testbench 
is completed, control passes to the interactive prompt. To dynamically load a second testbench, enter 

$reset 

$ vera_load ( * router 2 . vro " ) ; 
This example resets the simulation and runs the testbench router2. 

The $vera Joad and $vera_mload commands explicitly set the name of the files to be run with the 
simulation. A reset and restart causes the same testbench to be run again. This allows you to quickly run 
testbenches again and again. If you want to run a second set of testbenches after the first, you must ex- 
plicitly set the new files to be run. 



Note - If the new testbench has a different interface specification, has 
different global variables, or declares different HDL tasks, the shell file 
produced at compile time must change. In this case, you must recompile the 
source code. 

For example, if the third testbench uses several object files contained in a Vera list file, enter 

$reset; , 

$vera_load(* m ) 

$vera_mload( m router3 - vrl* ) ; 

This example resets the simulation. The second line clears the current testbench being used. The third 
line specifies the list file to be used with the new testbench. . 

1 8,8 Running Vera Stand-alone 

Vera includes a stand-alone, cycle-based simulator. To invoke the simulator; 

vera -run vera_execu table shaulator_options object_files 
verajexecutoble - The vcrajcxecutable is the compiled Vera source code being run. 
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simulator _options - The simulator options and their definitions are listed in Table 18-6. 
Table 18-6 Simulator Options 



Option 


Definition 


-o 


Terminates simulation on error 


-f 


Specifies list of Vera object files to load 


-« 


Pauses simulation on error 


-t 


Opens debugger in text mode 



object JUes - Object files used as part of the simulation are listed in the command line, separated by 
white space. 

-e 

The -e option terminates the simulation when an error is encountered. The syntax is: 
-e 

-f 

The -f option loads multiple object files from a Vera list file. The syntax is: 
-f .filename 

filename - The filename is the name of the .vrl file containing the list of object files to be run. 
-s 

The -s option pauses the simulation when an error is encountered. The syntax is: 
-« 

When an error is encountered, the simulation pauses until you enter a carriage return; 
-t 

The -t option launches the text debugger when an error is encountered. The syntax is: 
-t 

The default setting launches the graphical debugger when an error is encountered. K * 

Vera stand-alone is a cycle-based simulator, which runs without an HDL description and in conjunction 
with C for high-level modeling. All interface clocks are driven with the same timing. These system 
functions and tasks work differently: 

delayO returns immediately (with a warning). 

get.timeO always returns zero. 

SynopsysJnc ; 
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Note - To use the Vera stand-alone cycle-based simulator, you must compile 
an executable. This procedure is documented in Section 2.6, "Running the 
Vera Stand-Alone Simulator." 
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19. Vera Source-Level Debugger 

This chapter details the Vera Source-Level Debugger. It includes these sections: 

• Overview 

• Interactive Debugging 

• Contexts 

• Debugger Expressions 

• Text-Based Debugger Commands 

• Graphical Debugger 

19.1 Overview 

The Vera debugger is an interactive interface that allows you to step through Vera code, granting tre- 
mendous debugging power. It includes an easy-to-use graphical front end along with a powerful text- 
based interface. 

Vera incorporates powerful simulation debugging tools within its debugger, including the notion of cy- 
cles and timing, interface clocks, multiple thread analysis, and support for re-entrant and recursive 
code. These tools allow you to control and observe the simulation from the testbench perspective. 

The Vera debugger is used to debug Vera code, and it does not affect the debugging or execution of oth- 
er HDL code or waveform display tools. Thus, you can use the Vera source-level debugger in conjunc- 
tion with existing HDL graphic packages, HDL debuggers, and waveform displays. 

19.2 Interactive Debugging ; - ^ 

The Vera debugger is activated when one of several events occur . 

• A Vera breakpoint is encountered 

• The Vera debugger is invoked from the HDL command line 

• A verification error such as a failed expect or a timeout occurs 

■• A runtime error such as an improper bind or invalid index occurs . . 

If you want to use the graphical debugger while running a simulation with an HDL, you must run the 
simulation with the +vera_debug_on_crror plus argument for Verilog (see Section 18.5, "Running 
Vera with HDLs**) or the vcra.ini token vera_debug_on_eiror on for VHDL (see Section 173 X **VH- 
DL Plus Arguments**). 

You should compile all Vera source files with the -g switch if you want to run the Vera debugger with 
all symbolic information for the files included. 
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19.3 Contexts 

In Vera, a context refers to a thread of execution. Vera assigns each context a unique ID internally, 
which is used to identify contexts within the debugger. When using the debugger, you can switch be- 
tween contexts to examine code execution in any context within the simulation. 

A new context is generated under several circumstances: 

• A Vera simulation is launched 

• A fork is executed 

• A function or task is called 

Note that because Vera allows non-blocking forks, a procedure may finish, but its context may still be 
alive (as children it has forked may not have finished yet). This is the reason for assigning a context not 
only to each fork, but also to each procedure call. 

The context determines the variables that are visible in the debugger. The variables in the current con- 
text arc always visible in the debugger. This means that any local variables as well as global variables 
arc visible. If shadow variables are used within a fork context, they are visible and hide variables of the 
same name in the parent context 



19.4 Debugger Expressions 

The Vera debugger supports a subset of the valid Vera expressions. Expressions can contain variables, 
interface signals, and integer constants. Expressions can also contain these operators: -, *, /, %, &, I, A , 

K A ~, &&, II, «, ». <, >» <=. =>. =t !=t =. !==. =?=» and !?=. Expressions can also contain 
these unary operators: ~, !, &, I, -I, and - A . 

Expressions can use variables. However, the expression can only be evaluated if the variable is visible 
in the current context 

19.5 Text-Based Debugger Commands c 

When the text-based debugger is launched, you can enter commands at the debugger prompt A com- 
mand consists of a single line of input, starting with a command name. Multiple commands can be is- 
sued using semicolons (;) to separate them. If there is a conflict between an identifier and a Vera 
debugger command, preface, the identifier with a slash (/)• For example: 

print \print 
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The valid texl-based debugger commands are listed with a brief definition in Table 19-1. 
Table 19-] Vera Text-Based Debugger Commands 



51 
Q 

hi 

B 



Command 



Definition 



break line_num 

clear break line_num 

show break 

print exp 

assign var=expr 

show vara 

show context 

source file filename 

end 

echo * string* 

context context_id 

np 

down 

where 

list line^num, ilines 
show file 
watch add *exp' 



Continue 
Step 

Step in context 

Next in context 

Set break point 

Clear break point 

Show break points 

Prints value of expression 

Assigns value to expression 

Shows accessible variables 

Shows active context lists 

Reads commands from, a file 

Terminates a source file 

Echoes a string 

Switches contexts 

Changes to parent context 

Changes to child context 

Shows current location 

Lists source of context 

Shows source files 

Adds a watch expression 



watch change vatch_itf m exp" Changes a watch expression 
watch insert watch^id m exp* Inserts a watch expression 



watch 
show watch 
save filename 
restore filename 
guit 
close 
help 

radix num_hase 
'''window 



watch_id* 



Removes : a watch expression 
Prints the watch list 
Saves environment settings 
Restores environment settings 
Exits the simulator 
Closes graphical debugger 
Prints debugger commands 
Sets the default radix 
Launches graphical ; ^debugger 
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19.5.1 Execution Control 

The Vera debugger has several commands used for execution control. 

The . command is used to continue the Vera simulation. The simulation continues from the last break- 
point or error point 

» 

The , command is used to step through the Vera program. The very next executable statement in the 
Vera program is executed, regardless of context, and the simulation stops. 



The command is used to execute the next step within the current context When this command is in- 
voked, the very next Vera statement within the current context is executed, and the simulation stops. If 
other code must be executed before the next statement in the context is executed, that code is executed. 
This command executes the next step in the context unless that step is within a fork/join none. In that 
case, the first line after the fork/join none is executed. 

ft 

The „ command is used to execute the next statement within the current context Statements within sub- 
routines and forks are not executed with this command. Instead, the first statement after a subroutine or 
fork is executed. 

break 

The break command sets a break point at the specified line within the specified file. The syntax is: 
break filename^ l±ne_number 

filename • The filename is the filename in which the break point is to be set If no filename is set, the 
current file is used. 

line_number - The linejnumber specifies the line where the break point is set 
This is an example of a break command: 
break myfile@ 53 

clear break 

The clear break command clears the specified break point The syntax is: 
clear break filename^ linejnumber 

filename - The filename is the filename from which the break point is to be cleared. If no filename is 
set the oinedt file is use^ - - 

-r- 
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line_number - The line^number specifies the line where the break point to be cleared is. If no line 
number is specified, all breaks in the specified file are cleared. 

This is an example of a dear break command: 
clear break myfilee 53 

show break 

The show break command lists the active break points in all files of the simulation. 

19.5.2 Displaying and Updating Data 

The Vera debugger has several commands used to display and update data, 
print 

The print command evaluates the specified expression and shows the result The syntax is: 

print expression base 

expression - The expression can be any valid debugger expression, including arrays. 

base - The base determines the numeric base of the expression. It must be 0 (auto), 2 (binary), 8 (octal), 
10 (decimal), or 16 (hexadecimal). The default is set with the radix command. 

This is an example of the print command: 
print i+100 

If the expression is an array, you can optionally specify the number of array elements to print: 

print array_name num^el extents 
If you do not specify the number of elements to print, the current array limit is printed. 

limit array 

The limit array command sets the number of array elements printed with the print command. The syn- 
tax is: 

limit array num^elements 
The default value is 256. If you do not specify a number, the command returns the current array limit 

assign 

The assign command assigns a value to the specified variable. The syntax is: 

assign variable = expression 
variable - The variable can be any variable visible in the current context. 
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expression - The expression can be any valid debugger expression. 



Note - Assignments to interface signals are done immediately, without 
waiting for the corresponding drive clock edge. 



show vars 

The show vars command shows the variables in the current context. It displays the data showing the hi- 
erarchy of the call/block structure. For example: 

show vars 

List of active variable at program, main 162 in . . 
File: /foo/foo.vr 

program main 
{ 

integer i; 
integer j; 

class class_b. 
{ 

integer int_array [50]; 
integer int_asoc [ ] ; 
task local_array_check 
( 

integer flag, 
integer f lagl 

) 

{ 

integer local_var; 

19-5.3 Accessing Context Information 

The Vera debugger supports several command used to access context information. . 
show context 

The show context command shows the active contexts. For example: 
show context 

Context_ID : 4 0 6 STATUS : READY 

Location: CALL in program main (cls_dbg.vr, line 162); 

READY in task foo (bar.vr, line 77) 
Context_ID:0 STATUS : CALLING 

Location: CALL in program main (cls_dbg. vr, line 162) 
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source file 

The source file command executes commands from a specified file. The syntax is: 

source file filename 
filename - The filename is the name of the file that contains the commands. 
The source file command is particularly useful when the same commands are issued repeatedly. 



The echo command is used to echo a string to the terminal window. The syntax is: 
echo ~ string* 

string - The string can be any string of characters, encapsulated by quotes, 
context 

The context command is used to change contexts. The syntax is: 
context context_id 

context Jd - The context Jd is the unique numeric identifier assigned to a context If no context Jd is 
specified, the command returns the identifier of the current context 



The up command changes contexts to the parent context. The parent context is the context from which 
the current context was called or forked 

down 

The down command changes contexts to the child context If there is more than one child context, the 
command returns a message and the context is not changed. w 

where 

The where command shows the last executed Vera statement and context For example: 



end 

The end command is used to terminate the execution of a source file. 



echo 



up 



where 

Location: CALL in program main (foo.vr, line 162); 
READY in task bar (foo.vr, line 77) 



19.5.4 Accessing Source Files 

The Vera debugger provides several commands for accessing source files. 
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list 

The list command lists the specified lines of Vera source code. The syntax is: 
list filename^ line__nwnber, nwn_of_lines 

filename - The filename is the filename from which the source code is taken. If ho filename is specified, 
the code from the current file is displayed. 

line_number - The line_number specifies which line of code is the first line displayed. If no 
line_number is specified, the list of source code starts five lines before the current line. 

num_pfjines - The numjofjines specifies the number of lines displayed. If it is not specified, 20 lines 
of code are displayed. 

In the listing, there is a column between the line number and the source code. In that column, an S in- 
dicates a break point, and a > indicates the current line. For example: 

list , 7 

157 trigger(OFF, clsa.which^event (i) ) ; 

158 } 
159 

160 i = 0; 

161 j = 0; 

162 > foo(0, 2); 
163 

164 S i++ ; 

165 printfCi = %0d\n", i) ; 

Note that blank lines are numbered but do not count towards the number of lines of code displayed. 

show files 

The show files command shows the names of the loaded Vera source files. 



19.5.5 Watch Commands 

The Vera debugger supports several commands used in conjunction with its watch windows. The watch 
windows are used to show all the variables in the current context, including global variables, and their 
values throughout the simulation. A second set of watch windows shows user-selected expressions and 
their values throughout the simulation. Each expression in the watch windows is given a unique numer- 
ic identifier used to manipulate watch expressions. 

watch add 

The watch add command adds an expression to the watch windows. The syntax is: 
watch add "expression" base 
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expression - The expression is any valid debugger expression using variables in the simulation. Only 
when the context of the variables is shown will the expression be evaluated. 

base - The base must be 0 (auto), 2 (binary), 8 (octal), 10 (decimal), or 16 (hexadecimal). The default 
setting is set with the radix command. 

watch change 

The watch change command changes an existing watch expression. The syntax is: 
watch change watchjnumber * expression' base 

watchjnumber - The watchjnumber is the unique numeric identifier of the watch expression you want 
to change. 

expression - The expression is the new expression you want to assign to the watch number. It can be 
any valid debugger expression. If the expression is omitted and the base is include^ only the base 
changes. 

base - The base must be 0 (auto), 2 (binary), 8 (octal), 10 (decimal), or 16 (hexadecimal). The default 
setting is 0. If it is omitted, the base from the previous expression is used. 

watch insert 

The watch insert command inserts a watch expression with a specified watch number. The syntax is: 

watch insert watchjnumber m expression" base 

watchjnumber - The watchjnumber is the unique numeric identifier of the watch expression you want 
to insert 

expression - The. expression is the new expression you want to assign to the watch number. It can be 
any valid debugger expression. If the expression is omitted and the base is included, only the base 
inserted. 

base - The base must be 0 (auto), 2 (binary), 8 (octal), 10 (decimal), or 16 (hexadecimal). The default 
setting is 0. The default is set with the radix command. 

watch remove 

The remove watch command removes a watch expression. The syntax is: 

remove watch watchjnumber 
watchjnumber - The watchjnumber is the number of the watch expression you want to remove. 
If you do not specify a watch number, all of the watch expressions are removed. 

show watch 

The show watch command shows all the current watch expressions and watch number identifiers. 
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1 9.5.6 Debugging Environment Control . 

The Vera debugger supports several commands for controlling the debugging environment, 
save 

The save command saves the current environment settings to a file. The syntax is: 
save filename 

filename - The filename specifies which file the environment settings are saved to. If no filename is 
specified, the settings are saved to verajiebugjauto.rc. 

The environment settings that are saved include: breakpoints, the current radix, array limits, and watch 
expressions. 

restore 

The restore command restores environment settings from a specified file. The syntax is: 
restore filename 

filename - The filename specifies the file containing the environment settings to be restored. If no 
filename is specified, the settings are restored from vera_debug_auto.rc. 

quit 

The quit command exits the simulation. When you quit, the current environment settings are saved in 
the file verajiebugjamto.rc* 

19.5.7 Miscellaneous Commands 

The Vera debugger supports a set of miscellaneous debugger commands. 

close ' 
The close command closes the graphical debugger interface. 

help 

The help command lists the debugger commands with a short definition of each, 
radix 

The radix command sets the default radix. The syntax is: 
radix base 

base - The base must be 0 (auto), 2 (binary), 8 (octal), 10 (decimal), or 16 (hexadecimal). The default 
setting is 0. The default is 0. (ii itl : 
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window 

The window command launches the graphical debugger interface. 

19.6 Graphical Debugger 

The Vera graphical debugger can be invoked from the text-based debugger or launched when the debug 
mode is entered if the -t runtime option is not used. 

The button names and their corresponding text-based equivalent arc listed in Table 19-2. 
Table 19*2 Graphical Debugger Button Definitions 



Button Name Text-based Equivalent 



show vars 


show % 


'arc 


print <exp> 


print 




watch <exp> 


watch 


add 


unwatch <exp> 


watch 


remove 


close 


close 




quit 


quit 




where 


where 




step 


# 




stepc 






nextc 


# » 




cant 






up 


up 




down 


down 




brk <sel> 


break 




clr brk <eel> 


clear 


break 


auto 


radix 


0 - 


set radix 


radix 





When using the print, watch, and unwatch command buttons, you must use the mouse to highlight th< 
expression you want to print, watch, or unwatch. 

When using the brk and clr brk command buttons, you must use the mouse to highlight the line you 
want to assign a break to or clear a break from. 

19.6.1 Usage Notes 

The current simulation cycle and simulation time are shown in the top bar of the debugger window. I 
you are running multiple modules, the module name is also shown in the bar. 
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The watch windows to the right of the debugger interface show the watch expressions and variables 
with their values throughout the simulation. These expressions are only evaluated when the variables 
they include are in the current context (see Section 19.5.5, "Watch Commands"). 

Right-clicking on an expression, array, or class in a watch window invokes an expansion window that 
shows an expanded value of the chosen element. Expressions are expanded and shown in their entirety 
when they are selected. When an array is selected, the elements of that array are shown (the number of 
elements shown depends on the array limit). When a class is selected, the class is expanded and shown 
in the expansion window. Further, arrays and classes within expansion windows can be expanded (sin- 
gle values cannot be expanded from an expansion window). 



Note - Expansion windows are static and only show the selected element at 
that moment of time in the simulation. When you step through the program, 
they are cleared. 

The bar under the context window always shows the current context Double-clicking any context in the 
list changes the current context. The bar under the file window always shows the current file. Double- 
clicking any file in the list changes the current file. When the current context and current file are sepa- 
rate files, the color of their respective bars does not match. 

Text-based debugger commands can be issued from the command box at the upper right corner of the 
debugger window. 

19.6.2 Notes for Tcl/Tk Users 

By default Vera uses a copy of the Tcl/Tk wish shell and libraries, which reside in the Vera directory. 
You need to have Tel 7.5 and Tk 4.1 (or higher) installed and within your path. Note that Tcl/Tk is not 
part of Vera. However, Vera 3.1 and higher includes a pre-compiled version of Tcl/Tk, which gets 
picked up automatically by the source debugger. 

If you want to extend or modify the graphic window, you can edit 

$VERAJiOME/bin/verajdebuggentcU create a new version, and use it by specifying your script instead 
of the Vera default, from the debugger prompt: 

window wish^name tcl_file 
If you modify this script, Vera invokes it as follows: 

wish .-f $VERA_HOME/bin/vera_debugger.tcl processed 
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Appendix A. Quick Reference 

This appendix includes quick reference information in these 

• Vera Files 

• Vera System Functions and Tasks 

• Compiler Switches 

• Vera Debugger Commands 

A.1 Vera Files 

These are the Vera file extensions and their definitions. 



Filename Definition 



filename. vr 


Vera 


source file 


filename, vro 


Compiled Vera object file 


filename, vrh 


Vera 


header file 


filename, if .vrh 


Vera 


interface file 


filename, vrl 


Vera 


list file 


filename . vshell 


Vera 


shell file 


f ilename. test_top . v 


Vera 


Test- top file for Verilog 


filename. top 


Vera 


top file for VHDL 


f i 1 ename_ t op . vhd 


Vera 


test-top file for VHDL 


f ilename_intf . vhd 


VHDL 


interface file 


vera . ini 


Vera 


initialization file for VHDL 


f ilename . vc on 


Conf iguration file 


filename . pro j 


Project file 


filename. shell. v 


Vera 


shell file for multiple modules 



A.2 Vera System Functions and Tasks 

alloc (type, type_id. type_count [, key_countl) ; 

M0oc_lndex (command, array^name, index) ; 

atobinO; 

a tohex ( ) ; 

atoiO; 

atooctO; 
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backref ( index) ; 

bittostr (bit [high: 1 ow) bit_string) ; 
boundary {which) ; 

cast_asaign(dest — var, source^exp [, check] ) ; 

com traint_mode ( swi tch [, cons train t_narae] ) ; 

coverage ( command [, object_list] [, "filename*} ) ; 

delay (time) ; 

error ( * £mt_s tr* ) ; 

error_mode(ti'pe, error^class) ; 

exit (status) ; 

f close ( file_descriptor) ; 

£lag( lvalue] ) ; 

fopen ("filename*, * t.ype* ) ; 

fprintf {file_descriptor t fmt^str) ; 

freadb ( file^descriptor) ; 

f readh ( file_descriptor) ; 

f readatr ( file_descriptor, mode) ; 

get_bind(IJD]) ; 

get_bind_id(biu4_expression) ; 

getc(i) ; 

get_cycle ( ) ; 

get_plus_arg(reguest, plus_arg) ; 

get_atatua ( ) ; 

get_status_msg ( ) ; 

get_systime ( ) ; 

get_time ( word) ; 

itoa(i) ; 

len(); 

mailbox_get( vait_option, mailbox_id [, dest^var [, cheeky option] ]); 
mailbox_put {mailbox^id, data) ; 
mailbox_receive {wait_option, mailbox^id) ; 
mailbox_aend (mailbox_id f data); 
match {pat tern) ; 

pack (array, index, left, right); 
po« tmatch ( ) ; 
premat ch ( ) ; 

print £ ( • fm t_s tr m , argl t arg2 , . . . , argN) ; 

prodget ( {product ion_name {, occurrence_number] ]); 

prodeet (value [, product ion^name (, occurrence__number] ]); 

putc (i, * char m ) ; 

query [command ( I [ , bin^type] , bin_pattern] , operand, hit}); 
rand48 ( [seed] ) ; . 

rand_mode ( swi tch t, variable_name t, index] ]); 
random ( [seed] ) ; 
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a 

N 

IL.J 
if "1 

St 

UJ 
s 

Q 

t ; 

n - 
CJ 



randomize ( ) ; 

region_enter (urait_ option, region_id, valuel, value2, . valueN) ; 
region_exit (region_id, valuel, value2, . . . , valueN) ; 
rewind ( fi le^descriptor) ; 
search (pa t tern ) ; 

semaphore_get (wait_option, semaphore^ d, key_weight) ; 
semaphore_put ( semaphore_id, key_weigh t ) ; 

Bignal.connect {port^signal , target_signal [, attributes [, clock} ]); 

apr intf (string_name, string_ format) ; 

Bflcanf {string_name, string_ format) ; 

■top ( ) ; 

«ubstr(i, j); 

«UBpend_thread ( ) ; 

eync ( sync_ type , eventl, event2, . . . eventivl ; 
thiamatch ( ) ; 

timeout <o2?ject_t}'pe» cycle_limit [, object_id]) ; 

trace (request, object [ , idLIevel] ) ; 

trigger ( [ trigger_type t ] event_name) ; 

unpack (array, index, left, right); 

urand48 ( {seed] ) ; 

urandom( [seed] ) ; 

vca ( swi tch ( , signal_najnel ) ; 

vera_f ree_arg ( veranda ta ) ; 

vertjget.arg ( index) ; 

vera_num_arg ( ) ; 

vera_put_arg ( index , veranda ta ) ; 
vera_return_value ( veranda ta) ; 

v«v_call_func (connection, time_mode, func_name, return_value [, opt_args}); 
v«v_call_tae)t( connection, time_mode, task_name [, opt_argsl) ; 
vfv.clofe.conn ( conn ec t i on ) ; 
w get conn_err ( ) ; 

vevjnalce.client ( "host* , port, authentication) ; 

vBv_make_eerver(port, authentication £, verbose}); 

v*v_up_connectiona ( tineou t ) ; 

vav_wait_for_done ( ) ; 

v«v_wait_f or_input ( wai t_piode) ; 

wait_child<) ; 

wai t_yar ( var i abl es ) ; 
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A.3 Compiler Switches 

These are the compiler switches for use with the Vera simulator 



Option Definition 



-help Lists valid compiler options 

-cap Compiles Vera source files 

-alim Sets maximum number of elements 

in arrays 

-ansi Invokes ansi preprocessor 

-g Invokes compiler using debug 

information 

-h Updates .vrh file 

-hnu Updates .vrh file only if it has 

changed 

-i Produces ASCII interface 

definition 

-ip Compiles an IP core 

-max_error Sets the maximum number of errors 
before compilation failure 

-Q Compiles in quiet mode 

-timescale Sets timescale 

-top Creates VHDL top file 

-vhdl Processes VHDL top file 

-X> Specifies text macro 

-I Includes directory in search path 

-pp Invokes preprocessor 

-proj Creates Vera shell files from 

project file 

-run Runs simulation 

-tern Invokes Vera template generator 

-c Specifies clock signal 

-d Specifies dump file 

-nav Uses Magellan for simulation 

control 

-t Specifies Verilog module name 

Returns the compiler version 
number 

-vcoa Generates a .vcon file 
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These are the switches for use with Vera-CS. 



Option 


Definition 


-o 


Exits simulation on error 


-f 


Includes .vrl file in the compile 


-i 


Specifies initialization file 


-B 


Pauses simulation on error 


-t 


Invokes text -based debugger 



These are the Vera plus arguments. 



Plus Argument Definition 



+vera_ load 


Specifies a single object file 


+vera_mload 


Specifies a file with a list 




of object files 


+vera_stop_on_error 


Execution stops on simulation 




error 


+vera_continue_on_error 


Execution continues after 




verification error 


+vera_ exit_on_error 


Exits simulator on error 


+vera_f inish_on_end 


Exits simulator when 




simulation finishes 


+vera_debug_on_error 


Invokes Vera debugger on error 


+vera_text_debug 


Launches the Vera text 




debugger on error 


+vera_semaphore_size 


Specifies maximum number of 




semaphores 


+vera_region_size 


Specifies maximum number of 




regions 


ver ajnai lbox_s i ze 


Specifies maximum number of 




mailboxes 
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A.4 Vera Debugger Commands 

These are the Vera text-based debugger commands. 



Command 



Definition 



break line_num 

clear break line__num 

■how break 

print exp 

assign var^expr 

show vars 

show context 

source file filename 

end 

echo "string* 

c ont ext context_id 

up 

down 

where 

list line_num, § lines 
show file 
watch add m exp* 
watch change watch_id m exp* 
watch insert watch^id *exp" 
watch remove watch_id 
show watch 
save filename 
restore filename 
quit 
'close 
help 

radix num^base 
window 



Continue 
Step 

Step in context 
Next in context 
Set break point 
Clear break point 
Show break points 
Prints value of expression 
Assigns value to expression 
Shows accessible variables 
Shows active context lists 
Reads commands from a file 
Terminates a source file 
Echoes a string 
Switches contexts 
Changes to parent context 
Changes to child context 
Shows current location 
Lists source of context 
Shows source files 
Adds a watch expression 
Changes a watch expression 
Inserts a watch expression 
Removes a watch expression 
Prints the watch list 
Saves environment settings 
Restores environment settings 
Exits the simulator 
Closes graphical debugger 
Prints debugger commands 
Sets the default radix 
Launches graphical debugger 
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These are the graphical bugger button definitions. 



Button Name 


Text-based Equivalent 


show vars 


show vars 


print <oxp> 


print 


watch <exp> 


watch add 


unwatch <exp> 


watch remove 


close 


close 


Qllit 


quit 


where 


where 


•tap 




stepc 




nextc 


§ 9 


cont 




up 


up 


down 


down 


brk <sel> 


break 


clr brk <sel> 


clear break 


auto 


radix 0 


set radix 


radix 
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Appendix B. Vera 4.0 BNF Diagrams 



B1 . Vera-H VL: The Language 



B1.1 Program Structure 



Vera-HVL 



^ — subprogram file 



program file 



program file 



Interface declarations 



^>rogran^"» program name"}— top block 



program name 



Identifier 



top block 




{) (begin 



^~-| variable definWon]*-^ ^— 



task&function definition 



j*^ statement \—>^ 




subprogram file 



Interface declarations 



DJ2 



task&function definition 
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interface 
declarations 




interface definition 



port definition 



bind definition 



coverage block 



coverage definition 



sysdockpath 




task&function 
definition 





function declaration 










task declaration 





exported function declaration 



exported task declaration 



function definition 



task definition 



class definition 



typedet definition 



external declaration 



HDL task declaration 



User Defined task&function declaration 




n 



external 
declaration 




external variable definition 



external task declaration 



external function declaration 



external class declaration 
external HDL task declaration 



enum type definition \ 
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B1.2 Interface Definition 



Interface 
definition 



^interface) -*- 



Interface name 



interface signal definition 



h. 



interface dock 



Interface name 



identifier —* 



Interface 
signal 
definition 






interface 




signal 






signal list 




smpl&drv 






Interface 
signal list 



range 




signal name 



identifier 



signal s ■ \ 

smpl&drv ( i ■ 1 J 

siana ttvoe — 



signal type 



depth V* integer 



signal vca 




skew 



C#y~ lnleger\ +* 
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negative skew /7\ 



ne 9 ative integer 



signal vca 




interface 
clock 



signal name -^CLOCK^ 




HDL path 
to node 




HDL module 
name 




HDL signal \ *f*y+ 



HDL module 
name 



identifier 



HDL signal n 



identifier 



> 
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B1.3 Variable Definition 




^integer)- 




coverage name 



G scalar 
variable \ 
variable 



range 



(Ty* integer /nteger -^J^)-*- 



scaiar variable 



variable name 



^—^Ty* expression | 



a/ray variable 



— 1 — 7^Ci)^ 

»| a/ray d/roensfoT| ' 



variable name 



identifier 



array dimension 



integer 



external variable definition 



extern V* variable definition 
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B1.4 Expressions 



constant expression 



variable expression 



expression}*] 0 J^ f H expression \ - 



expression 



expression 



constant expression 



-^T^-^ expression -»(T > )*» j expression 



^7^-*- expression -^7^ 



state expression 



function call 



concatenation 




blnary_number 



octaJ_number 



dedmaljnumber 



hexadedmaljnumber 




size 



integer 



variable expression 



interface 
/~ signal \ 

\ ,| dassl.r^ /^\-Jv^^| / \ l 

* specifier I name I 



range 
selection 



range selection 



integer | ^ 



integer 
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binary 
operator 




arithmetic operator 



bitwise operator 



logical operator 




arithmetic operator 




bitwise operator 




logical operator 




relational operator 




unary 
operator 
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B1 .5 Statements 




(breakpoint}-»(T)- 



d variable definition U-v stat ement] ^ 
^ > (jy 



assignment 



assign expression 



assign 
expression 



<2 



variable expression 



assign operator expression}— 



assign operator 




coblock construct 



S m coblock | v 

^ — i^tcniiinate^^T) ' 




coblock 
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B1.6 Interface Signal Control 



Interface signal 
control 




drive 



sync 
drive 



sync drive 



async drive 




drive 


signal 




to drive 



delay offset 



delay value 



delay value 



expression 



signal 
to drive 



Interface signal 



bind 
name 




port name 



Interface signal ^ ^y^^^ 



expect 



sync expect 



async expect I 



sync expect 



delay window 



* \ expect Us!\ 
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async expect 




window value 



expression 



expect list 



or expect 



and expect 



or expect 



expect expression 




and expect 



expect expression 




expect 
expression 1—7 



signal to expect 




signal 
to expect 



interface 
signal 



depth selection 



bind name 



port 




signal name 





range selection 



depth selection 



Integer [ ■»» 



sample 



■] Interface signal 


1 - ■ J 






range siection 


^ — async /— — ^ 



sync 



sync expression 
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sync expression 
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B1.7 Sequential Control 



sequential 
control 
construct 




Ifelse 



(^y^Ty* expression "statement \ 



statement 



while 



^whHe^ -»^T^-» expression -*^7^"* statement 



for . 



^fo^-*- for loop construct -* \ statement 



for loop 
construct 



for 
expr 



<s> 



expression 



<•> 



for 



<D- 



tor 
expr 



I 



y ^ state expression | v 

^— assion expression 



ass/yn expression 



repeat 



^repeat^ ^T^ expression -*fT)H statemenl\+- 




(T) H expression h »(T)-^7 




/fern 



default 
case 
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esse Itent 




default 
case 



^default^ ^T ^ statement | — 



randcase 



^randcase)-^ item H ^T}^ 



break 



continue 
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B1.8 User Defined Types 



typedef definition 



^typede^ fr^ dass^ -» class name 



enum 
definition 




enum 
element 




o 




enum type 



identifier }— 



enum element 



identifier 




integer 




enum va/i/e 
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B1.9 Functions 



function 
definition 



(function) -* deMtteln -*(7)-^ p ■ ^"*(T}H^^K 

' SP6C ' 



function 
definition 
spec 



\type\- 



class 
name 




function name 



^ — » ^yith^ -» ] port name \ —f 



external function 
declaration 
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B1 .12 Classes 
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B1.13 Coverage Blocks 
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B1.14 Coverage Objects Definition 
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B1.15 Vera Stream Generator 
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B1.16 HDL Tasks 
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B2. Vera System Tasks & Functions 
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B2.2 String operations 
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B2.3 Input/Output 
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B2.4 Coverage Control 
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B2.6 Debug Support 
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B2.7 Simulation Timing 
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B2.9 Automated Stimulus Generation 
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B2.12 VERA-SV API 
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B3. Vera Simulator 
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CROSS TRANS 233 
CROSSJTRANS 241 
HI 233, 241 
L0 233 

NO_OVERLAP 233 

coverage reports 239 

coverage_def 224 

cross coverage 240-244 

illegal state declarations 228 

illegal transition declarations 231 

instantiation 235 

overview 223 

state declaration 225-228 

transition declarations 228-232 
state transition 229 

triggering coverage objects 235 
coverage_def 224 
coverage_goal 233 
coverage_val 232 
CROSSJTRANS 233, 241 

D 

debugger 

accessing context information 358-359 
accessing source files 359-360 
debugging environment control 362 
displaying and updating data 357-358 
execution control 356-357 
expansion windows 364 
expressions 354 
graphical debugger 363-364 
miscellaneous commands 362 
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radix 362 

text-based commands 354-363 
watch commands 360-361 
watch windows 364 
window 363 
debugger commands 
,356 
.356 
.356 
» 356 

assign 357 
break 356 
dear break 356 
close 362 
context 359 
down 359 
echo 359 
end 359 
help 362 
limit array 357 
list 360 
print 357 
quit 362 
restore 362 
save 362 
show break 357 
show context 358 
show files 360 
show vars 358 
show watch 361 
source file 359 
up 359 

watch add 360 

watch change 361 

watch insert 361 

watch remove 361 

where 359 
decimals 45 
delay() 82, 90, 350 
dist 188 

distribution sets 187-188 
drive 81-83 

blocking and non-blocking drives 82 

implicit synchronization 89 

soft and strong drives 83 

void drives 83 



enumerated types 47, 59-61 

increment and decrement operations 60 

mapping Vera types to VHDL 324 

use in numerical expressions 60 
error() 146 
error_mode() 147 
event variables 1 19-120 

bidirectional variables 120 
events 47, 116-122 

disabling events 121 

event variables 1 19-1 20 

merging events 121 

syncO 118-119 

timeout() 130 

triggers 117-118 
exit() 149 

expansion windows 364 
expect 84-87 

full expect 85-86 

implicit synchronization 89 

restricted expect 86 

simple expect 85 

strong and soft expects 86 

void expects 87 
export 277 

exporting external tasks 278 
external declarations 97 

F 

fdose() 142 

file indusion 336 

file input /output 142-145 

flagO 146 

FlexLM31 

backwards compatibility 34 

license file 33 

LM_UCENSE_FILE 33 

starting Flex License Manager 34 
fopen() 142 
for 108 

fork and join 111-116 
shadow variables 116 
suspend_threadO 115 
terminate 114 

wait_childO 113 , 
wait_var() 114 
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fprintf() 142 

ireadbO 143 

freadh() 143 

freadstr() 143 

functions 91-92, 93-97 
default arguments 95 
discarding return values 92 
external default arguments 97 
external functions 97 
optional arguments 96 

G 

get_bind() 71 
get.bind JdO 72 
get_cydeO 150, 225 
get_plus_arg() 151-152 
get_status() 53 
get_status_msg() 53 
get_systime() 150 
get.timeO 150, 225, 350 
getc() 52 

H 

HDL nodes 68-69 
hexadecimals 45 
HI 241 

I 

identifiers and keywords 42-44 

ifdef337 

if-else 105-106 

usage in VSG 210 
ifndef337 
in 187 

inheritance 159 
inout signals 67 
input signals 67 
installation 31 
integers 45 

interface specification 67-68 
clocking domains 69 
HDL nodes 68-69 
signal direction 67 
signal type 67 
signal width 67 
skew 67 



itoaQ 56 
J 

join 
See fork. 

K 

keywords 
See also identifiers and keywords 

L 

len() 52 

lexical conventions 

comments 41 

statement blocks 42 

white space 41 
lexical convetions 

numbers 44 
licensing 31-34 

HexLM 31 

lmhostid 32-33 

Vera license queueing 34 
UTJNTEGER44 
little_endian 196 
LM_UCENSE_FILE 33 
lmhostid 32-33 
local class members 162 

M 

m_bad_state 228 
m_bad_trans 231 
m.state 227 
m_trans 230 
mailbox_get0 128 
mailbox_putO 128 
mailbox_receiveO 131 
mailbox.sendO 131 
mailboxes 127-130 
allocO 128 

backward compatibility 131 
mailbox_get() 128 
mailbox_put() 128 
mailbox_receive0 131 
mailbox.sendO 131 
setting maximum number 323, 346 
timeoutO 130 
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match() 54 
ModelTech 

recompiling 37-38 
multiple clocking domains 

inVerilog319 

inVHDL 332 
multiple modules 

configuration files 254, 255-257 

generating a multiple module 
testbench 257-258 

overview 253-254 

project files 254, 255 

N 

negedge81 
newcov 235 
NHOLD67 
NO.OVERLAP 233 
not state 228 
not trans 231 
NR67 

NSAMPLE 67 
null events 47 
numbers 44 

O 

objects 154-157 

assignment 158 

constructors 156 

copying 158 

creating instances 155 

object methods 156 

object properties 156 

renaming 158 
octal numbers 45 
operators 61 
output signals 67 

P 

packO 197, 199-200 

post_pack() 200 

pre_pack() 200 
packed 196 

packing and unpacking 196-200 
pack0l97 

property attributes 196 



unpack() 198 

PHOLD 67 

plus arguments 
+vera_continue_on_error 345 
+vera_debug_on_error 345, 353 
+vera_exit_on_error 345 
+vera_finish_on_end 345 
+vera Joad 344 
+vera_mailbox_size 346 
+vera_mload 344 
+vera_region_size 346 
+vera_semaphore_size 346 
+vera_stop_on_error 344 
+vera_text_debug 345 

polymorphism 166 

port 
See virtual ports 

port variables 73-74 

posedge 81 

postmatch() 55 

PR 67 

prematch() 54 
printfO 141 
prodget() 213 
prodset() 213 

production definition 207-208 
production items 208 
production weights 209 
project files 254, 255 
property attributes 196 
protected class members 162 
PSAMPLE 67 
putc() 52 

Q 

queryO 225, 237-238 
query_str0 238 

R 

rand 179 
rand_mode() 186 
rand480 146 
randc 179 
randcase 107 

random numbers 145-146 
setting seeds at compile time 324 
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random packet generation 178-190 
random variables 178 
active and inactive random variables 
186 

random() 145 
randomizeQ 180-182 

post_randomize() 181 

pre_randomize() 181 
randseq 207 
reg46 

rq*ion_enterO 125 
region_exitO 126 
regions 125-127 
alloc() 125 

conceptual overview 125 

region_enter() 125 

region_exit() 126 
rj setting maximum number 323, 346 
43 timeout() 130 
H repeat 107-108 
yi usage in VSG 211 
□ return 93 

P rewind() 144 

01 

u s 

«*. sample 84 

implicit synchronization 89 
L searchO 54 
f!j semaphore_get() 122 
O semaphore_put() 123 
w* semaphores 122-125 

allocO 122 

conceptual overview 122 

semaphore_getO 122 

semaphore_putO 123 

setting maximum number 323, 346 

timeoutO 130 
shadow variables 116 
signal declaration 67-79 

HDL nodes 68-69 

interface specification 67-68 

signal depth 69 

signal direction 67 

signal type 67 , 

signal width 67 

stew 67 

virtual ports 70 



signal depth 69 
signal direction 67 
signal types 67 
signal width 67 
signaLconnect() 77 
simulation control 149-150 
simulation errors 146-149 

debug support routines 148-149 

error handling 146-148 
skew 67 
sprintfO 58 
sscanf()58 
state 

declaration 

m_state 227 
state bin name 226 
state declaration 225-228 

all 226 

illegal state declarations 228 
bad_state 228 
m_bad_state 228 

multiple state bin declarations 227 

state bin name 226 

state specification 225 

usage of conditionals 227 
state specification 225 
statement blocks 42 
static variables 94 
stimulus generation 

constraint blocks 186-190 

overview 177-178 

packing and unpacking 196-200 

random packet generation 178-190 

random variables 178 

randomizeO 180-182 
stopO 149 
string formats 50 
strings 44, 46, 50-59 

class methods 51-59 

pattern matching 53-56 
type conversion 56-58 

format specifiers 50 

printing strings 50 

string operators 5 1 
subclasses 159 
subroutines 91-97 

arguments 94-96 
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breakpoint 94 

default arguments 95 

external default arguments 97 

external subroutines 97 

optional arguments 96 

return 93 
substr() 53 
superclass 161 
support and feedback 39 
suspend_thread() 115 
sync 

See synchronization. 
syncQ 118-119 
synchronization 81 

implicit synchronization 89 

T 

tasks 92-97 

calling from an HDL 277 

default arguments 95 

exporting to HDL 277 

external default arguments 97 

external tasks 97 

optional arguments 96 
template generator 

for Verilog 309-312 

for VHDL 319-320 
terminate 1 14 
text macros 337 
this 157 
thismatch() 55 
timeoutO 130 
timescale 255 
traceO 148 
trans 228 

transition declarations 228-232 
all) 230 

illegal transition declarations 

m_bad_trans 231 

not trans 231 
illegals transition declarations 231 
m_trans 230 

multiple transition bin declarations 230 
state transition 229 
transition bin names 229 
use of conditionals 230 
triggers 117-118 



HAND.SHAKE 118 
ONE_BLASl 118 
ONESHOT117 
typedef 168 

U 

UDF 

C/C++ arguments 280 
declaring in Vera 279 
handling special events 285 
linking UDFs to Vera 28 1-284 
object files and vera_local.dl 282 
PLI support procedures 284-285 
Vera arguments 279 
Vera UDF table 281 

unpack() 198, 199-200 

unpacked 196 

unpacking 
See packing and unpacking. 

urand48() 146 

urandom() 145 

V 

value change alert 87-88 
var 

usage in UDFs 280 

usage with HDL tasks 276 
var arguments 95 
variables 

assignment 63 

declaration 45-50 

initialization 45-48 

shadow variables 1 16 

static variables 94 

vca ; 

See value change alert 
vca()88 
vcon files 

See configuration files 
Vera license queueing 34 
Vera Stream Generator 

SeeVSG. 
vera.ini 320-325 

map 324 

vera_continue_on_error 322 
vera_debug_on_error 323 
vera_exit_on_error 322 
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vera_finish_on_end 322 

vera_load 321 

vera_mailbox_size 323 

vera_mload 321 

vera_mload_define 321 

vera_rand48_seed 324 

vera_random_seed 324 

vera_region_size 323 

vera_semaphore_size 323 

vera_stop_on_error 322 

vera_text_debug 323 
vera_free_argO 285 
vera_get_argO 284 
veraJocaLdl 282 
vera_mtldl 283 
vera_num_arg() 284 
vera_put_arg() 285 
VERA_REASON 286 
vera_return_value() 285 
Vera-CORE 

overview 265-266 

usage model for IP users 267 

usage model for IP vendors 266 
Vera-CS 

recompiling Vera-CS 38 
Vera-SV 

backward compatibility 308 

C/C++ aspects 303-304 

initializing connections 295-297 

managing errors 298 

master-slave configuration 299 

overview 293-295 

servicing remote calls 297 

submitting remote calls 297-298 

troubleshooting 307 
Verilog simulators 

recompiling ModelTech 37-38 

recompiling Verilog- VCS 34-35 

recompiling Verilog-XL 35-37 
verilog_node 

See HDL nodes. 
verilog__task 275 
Verilog-VCS 

recompiling 34-35 
Verilog-XL 

recompiling 35-37 
veritask257 



vhdl_node 

See HDL nodes 
vhdl_task275 
virtual classes 164 
virtual ports 70 
void binds 75 
void constraints 189 
void drives 83 
VSG 

if-else usage 210 

overview 207 

prodget() 213 

prodset() 213 

production definition 207-208 

production items 208 

production weights 209 

randseq 207 

usa of break 211 

usage of case 210 

usage of continue 212 

usage of repeat 21 1 

value passing 212-215 
VSIM commands 325 
vsv_call_func() 297 
vsv_call_task() 297 
vsv_close_conn() 296 
vsv_get_conn_err() 298 
vsv_make_dient() 295 
vsv_make_server() 295 
vsv_up_connections 296 
vsv_wait_for_doneO 299 
vsv_wait_for_input() 299 

W 

wait^childO 113 
wait_var() 114 
watch windows 364 
while 109 
white space 41 
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